What the signup page may show someone holding an invite token.

THE ONLY UNAUTHENTICATED ROUTE IN THIS MODULE, and deliberately so: its whole purpose is to serve a person who does not have an account yet. The token is the authorization, exactly as it is for accept_invite below — secrets.token_urlsafe(32), stored only as a SHA-256, and delivered to one address.

POST, not GET, for a read. The token would otherwise ride in a query string and land in this service's own access log ("GET /v1/org/... 200" is logged for every request), which writes live invite tokens to disk. accept_invite takes its token in a body for the same reason, so the two invite routes at least agree on where a token belongs.

410 for BOTH a missing invite and a used, revoked or superseded one, with a message that does not say which — the same anti-enumeration posture as accept_invite, and the reason this cannot 404. Expiry gets its own message because it is the one case the holder can act on, and it tells them nothing they did not already know.

Deliberately silent about whether the invited address has an account. The page offers both tabs and does not need to know; answering would let anyone holding a token probe registration state for that address.