Refs #208 (replaces #251, whose description carried an incorrect rationale for rejecting email)

⚠️ Stacked on #250 (fix/235-nip05-case-insensitive). Base is that branch, not main — merge #250 first and this will retarget cleanly.

The lint refactor that was briefly on this branch now lives in #257, which is independent and based on main.

What this does

The setup field asked for a "Trustroots Account" without saying what that meant, and accepted only a bare username. It now takes the three shapes that can be resolved to a username without a lookup:

The code-entry fallback in onboarding/trustroots.tsx now goes through the same validator (it was doing a raw .trim().toLowerCase(), so @alice would have been sent un-stripped). The accepted formats are handled silently rather than advertised under the field — the label still asks for a username, which is what we want people to type.

Why an arbitrary email is still rejected

Not because we cannot resolve one — the earlier PR said that, and it was wrong. nr-bridge reads the Trustroots users collection directly, where email sits next to username as a unique, lowercased field, so an email→username lookup is entirely buildable.

It is a deliberate choice. Usernames are already public; emails are not. An email-keyed lookup would turn request_token into an oracle for whether a given address has a Trustroots account at all — free user enumeration against a set of addresses an attacker already holds. So the input is rejected with a short, friendly error pointing at the username, and the code comment now states the real reason.

#208 stays open: making email work is a product/privacy decision (and likely a rate-limited, authenticated endpoint), not a missing capability.

Tests

pnpm test in nr-app: 99 passing. Covers all three accepted shapes plus the rejected ones (foreign-domain email, multiple @, bare @).