fix(eims): map buyer Wereda to a MoR code too, fail locally if unmapped

BuyerDetails.Wereda had the same problem Region did: companies.woreda holds
names ("Yeka") MoR has no confirmed regex for, but every Wereda value MoR has
actually shown us (seller "12"/"13", the collection's "574") is 1-3 digits
like Region. Precautionary, not confirmed -- but the fix is identical either
way: resolve through EIMS_BUYER_WEREDA_CODES and refuse to file rather than
send a guessed code.

Generalises the Region resolver (resolveRegionCode -> resolveLocationCode) to
cover both fields instead of duplicating it.

No code was invented for "Yeka" -- EIMS_BUYER_WEREDA_CODES ships empty, so
this buyer now fails locally (new stop) instead of silently sending a name
that was never verified against MoR's schema.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

apps/edr-freight-api/.env.example

@@ -192,6 +192,9 @@ EIMS_BUYER_COUNTRY_CODE=
 # Buyer region name -> MoR numeric code. companies.region holds names; MoR wants ^[0-9]{1,3}$.
 # An unmapped region fails locally rather than being filed with a guess.
 EIMS_BUYER_REGION_CODES=Addis Ababa=13
+# Same mechanism for Wereda. MoR has never named a Wereda regex in an error (only Region's is
+# confirmed), so this is precautionary — but an unmapped name still fails locally, not filed as a guess.
+EIMS_BUYER_WEREDA_CODES=
 EIMS_CASHIER_NAME=
 EIMS_SALESPERSON_NAME=
 # Automatic filing of issued invoices (@Cron sweep, one invoice per tick).