[crstian19]

Closes #140

Why

USA and LATAM are open regions now. A signup from there is stored as a normal waitlist signup, the same as EU. But the form still showed USA and LATAM the text for a region that isn't open yet ("Noted. We are not open in your region yet…").

The form also showed a "position" (position 019 / 19) that was misleading:

• The number is a cumulative arrival counter, not a place in the queue.
• The "/ total" was the same number again.

Product decided to drop the position from the message.

What

• All three regions are treated as open. registerViaBackend no longer derives status from the region, in either the 201 or the 409 answer. The interest status and its okInterest copy (EN and ES) are removed.
• No position in the success message. Every region and every case (new signup, already registered, returning member) shows the same registered text:
  • EN: "You're on the waitlist. We'll approve your spot in the next few days. Keep an eye on your inbox ^__^"
  • ES: "Ya estás en la waitlist. Aprobaremos tu plaza en los próximos días. No pierdas de vista tu bandeja ^__^"
• The Worker no longer forwards the counter. position and total are dropped from the /api/waitlist response, which is now {ok, status: 'registered', region}. okPosition is removed from the copy.
• Compatibility: cached old JS from main reads the missing position / total as 0, so it shows the registered message without a position. status: 'registered' keeps it off the old "not open" branch.
• The region-model comment in src/lib/waitlist.ts is updated. community-signup, the confirmation email and the premium flow (?premium=1) don't read these fields, so they are unchanged.

Case	Before	After (EN)
USA / LATAM	"Noted. We are not open in your region yet…"	"You're on the waitlist. We'll approve your spot in the next few days. …"
EU	"You're on the waitlist. position 019 / 19 · …"	"You're on the waitlist. We'll approve your spot in the next few days. …"

Docs

ARCHITECTURE.md now documents the new response, { ok, status: 'registered', region }, with all regions open and no position.

Test

• npm test: 1337 tests in 66 files pass.
• npm run check: 0 errors, 0 warnings, 0 hints.
• npm run build passes.
• What the tests cover:
  • Success text: waitlistSuccessText no longer takes the response, so no field the Worker sends can reach the message. One test per language (EN and ES, real i18n copy) asserts the exact registered text, with no position fragment and no "not open" text.
  • Parser: it drops legacy position, total and status: 'interest'.
  • Worker: it returns status: 'registered' for USA and LATAM on both 201 and 409, and doesn't forward the backend counter.
  • Copy: neither the i18n dictionaries nor the messages that Hero.astro serialises into data-msgs contain okPosition or okInterest.
• Mutation: each behaviour change was reverted in a scratch copy and fails a test. The mutants covered:
  • the position fragment brought back;
  • the trailing period of okRegistered removed;
  • okPosition / okInterest brought back to i18n, the script or Hero.astro;
  • interest derived from the region again, in the 201 and the 409 answer;
  • the counter forwarded by the Worker or kept by the parser;
  • the honeypot sending a position.
• Cached old JS: the client from main, given the new response, shows the registered message for EU, USA and LATAM in EN and ES, without a position and without crashing.