Enforce username rules on every account-creation path

[jackowayed]

The bug

Username format rules — 2-20 characters, [a-zA-Z0-9_] only — were enforced only by POST /api/auth/username/check, which is advisory and creates nothing. The four paths that actually insert users ran only the profanity filter:

• email.ts — email registration completion
• oauth.ts via tryCreateOAuthUser — OAuth completion and both callback flows
• the native Apple and Google sign-in routes

A 300-character username containing HTML, newlines, and unicode was accepted and stored.

That matters because usernames are rendered directly into push notification bodies — `${user.username} sent you an Oy!` — so a stored username is attacker-controlled lock-screen copy for anyone who receives an Oy. The broadcast feature that just landed on main adds a second such call site.

The fix

validateUsername in lib.ts is now the single gate for every username reaching the users table: length, character set, then the profanity filter. normalizeUsername (previously dead code) trims and lowercases, matching how usernames are stored and compared via LOWER(username).

It's applied at each creation path. The two OAuth callback flows go through tryCreateOAuthUser, which now returns null for an invalid username — so instead of creating a user they fall through to the existing choose-username screen. The native routes return a 400 with the specific error.

The check endpoint now delegates to the same function, so advisory results and creation results can't drift apart again.

Also removes fetchUserByUsername, which had no callers.

Testing

Red-green: 8 tests written first, all 8 failing against the unpatched code, the rest of the suite passing to confirm the failures were the bug rather than a broken harness.

• tests/worker/username.test.ts — unit coverage for normalize, accept, length bounds, and rejection of HTML, newlines, an RTL override, emoji, spaces, hyphens, @, and profanity.
• email.test.ts / oauth.test.ts — integration tests driving each creation path with a 300-char HTML/newline/emoji username and with "zed\nsent you an Oy!". Each asserts the 400 and db.users.length === 0 / db.sessions.length === 0, so a regression that validates but still inserts would fail.

Rebased onto main after phulin#19 merged. Full suite: 108 passing. tsc -b exits 0, biome check clean.

Notes

• The demo-account path inserts hardcoded usernames and is unaffected.
• The client already caps the username field at 20 characters (ChooseUsernameScreen.tsx), so this doesn't tighten anything below what the UI allows.
• Existing accounts are not migrated. If any stored username already violates these rules, it stays as-is and stays in notification copy — worth a query against production before shipping.

[jackowayed]

phulin#20