docs: record confirmed CORS origin-allowlist gap for gorbushka domains

users.vitanova.network:456 flatly 403s the CORS preflight for
https://admin.gorbushka.market (no CORS headers at all) while
https://novo.market gets a full grant (204, explicit
Access-Control-Allow-Origin + wildcard Allow-Headers). This is a
server-side origin allowlist, not something the frontend can route
around - confirmed live via curl OPTIONS against both origins.

This makes item 1 (X-Marketplace-Domain CORS confirmation) load-bearing
for the gorbushka admin login fix in progress on the marketplaces repo:
the frontend fix is ready but cannot work until this origin is added.

BACKEND-TODO.md

@@ -2,13 +2,53 @@
 
 Everything here needs a decision or confirmation from whoever owns the central Auth API / Payment API. Nothing in this list can be resolved from the frontend side alone. Hand this file to them directly.
 
-## 1. Confirm `X-Marketplace-Domain` CORS support (blocking)
+## 1. Confirm `X-Marketplace-Domain` CORS support (blocking) — NOW LOAD-BEARING, ORIGIN ALLOWLIST CONFIRMED MISSING
 As of 2026-08-23, `@marketplaces/auth` and `@marketplaces/payment` send the marketplace domain as a request header (`X-Marketplace-Domain`) exclusively. The previous query-parameter/body fallback (`contextTransport: 'parameter'`, kept for backends that hadn't allowed the header in CORS preflight) has been **removed**, not just de-defaulted.
 
 **Backend must confirm**: both the Auth API and the Payment API allow `X-Marketplace-Domain` in CORS preflight (`Access-Control-Allow-Headers`), and reject requests with an unknown/disabled domain in that header. See `docs/BACKEND-CONTRACT.md` for the full contract.
 
 If either service can't allow that header for some environment (legacy proxy, CDN stripping custom headers, etc.), say so before this ships — the frontend has no fallback for it anymore.
 
+**2026-08-24 finding — this is now actively blocking the gorbushka admin login fix:**
+
+`users.vitanova.network:456` (the auth host) rejects the CORS preflight
+outright for gorbushka origins, before it even reaches app-level CORS
+logic:
+
+```
+OPTIONS /users/sessions  Origin: https://admin.gorbushka.market
+  -> 403 Forbidden, no CORS headers at all
+
+OPTIONS /users/sessions  Origin: https://novo.market
+  -> 204 No Content
+     Access-Control-Allow-Origin: https://novo.market
+     Access-Control-Allow-Headers: *
+     Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
+     Access-Control-Allow-Credentials: true
+```
+
+This is a server-side **origin allowlist** — `novo.market` is on it,
+`gorbushka.market`/`admin.gorbushka.market` is not. The frontend fix
+(pointing `AUTH_API_URL` at this host instead of the wrong tenant
+content origin) is ready but cannot work for gorbushka until this
+lands — no frontend change can route around a 403 the browser gets
+before the request is even sent.
+
+**Request:**
+1. Add the gorbushka origins to the allowlist on `users.vitanova.network:456`.
+   At minimum: `https://admin.gorbushka.market` and `https://gorbushka.market`.
+   Confirm if any other gorbushka-family origins need it too (subdomains,
+   `www.`, etc. — whatever the real deployment topology needs).
+2. Confirm the allowlist entry for these origins includes
+   `X-Marketplace-Domain` in `Access-Control-Allow-Headers` (novo.market's
+   grant above uses a wildcard `*`, which already covers it there — confirm
+   gorbushka's entry does too, don't assume the wildcard is uniform across
+   all allowlisted origins).
+3. Same allowlist question applies to `qr.vitanova.network` (payment) —
+   not yet checked for gorbushka origins, worth confirming in the same pass.
+
+Until this lands, no frontend change makes browser login work for gorbushka.
+
 ## 2. `@marketplaces/payment` version discipline
 `@marketplaces/payment` changed the same way as auth (dropped param-transport) but was never version-bumped past 0.2.0, even though it's a behavior-breaking change for anyone integrating against it. Not a backend question exactly, but flagging since payment's release process seems to have skipped a changeset for this — worth a process check.