Client half of flamenet-relay!13, which gates a relay token on a proved
email address.
🔴 **Without this the refusal is indistinguishable from a broken
password.** An unverified account arrives as a bare 403; `RelayAuth` logs
"minting failed" and falls back to Basic, which the e2e routes refuse. So
the person sees calls that do not work and an inbox that does nothing —
and nothing anywhere says the remedy is a code sitting in their inbox.
⚠️ **The status alone is not enough.** 403 is also "that device belongs
to another account". Telling somebody to check their email for that would
send them looking for a message that was never sent, so the relay's own
`code` decides, not the number. A 403 with no code, an unparseable body,
and the same code on a 500 all stay generic — three tests hold that.
`RelayAccounts.verifyEmail` spends the code. Unauthenticated on purpose,
exactly like reset confirm: the code IS the proof, and requiring a
session would mean somebody kept out *because* they are unverified could
never get in.
⚠️ **Kotlin nests block comments**, so a slash-star written inside a
KDoc — as part of a route glob — opens a comment that never closes and
takes the module down with ninety unrelated errors, none of them near the
real line. Cost twenty minutes here; there is now a note in the file.
Five tests, proven able to fail: removing the code check turns three red.
All three Android suites pass.
Paul Hitt