Hotfix: spurious /set-username redirect & userInfo undefined error

[HarmlessHarm]

Problem

Affected users are bounced to `/set-username` on login even though they already have a username (stored in the DB). The page then throws `TypeError: ... userInfo is undefined` (Firefox) / `Cannot read properties of undefined (reading 'username')` (Chrome). The same redirect was reproducible by anyone via ctrl-click / "open link in new tab" (a fresh SSR load).

Root cause

`userInfo` was committed (`SET_USERINFO`) only as the last line of an async `.on("value")` callback, after a chain of awaits — server time, tiers, a by-email `new_patrons` lookup, and `getActivePatreonTier`. Meanwhile `setUserInfo` resolved its returned promise on a hard-coded 1s timer, decoupled from that commit.

Two ways this broke:

• Per-user throw (the login case): the patron lookup runs by email, independent of whether an account links Patreon. A stale/corrupt `new_patrons/` record pointing at a renamed/removed tier makes `subscription.js` throw (`tier.order` on `undefined`) before `SET_USERINFO`. The callback aborts, `userInfo` never commits, the timer resolves anyway, and the route guard (which redirected on `!userInfo`) sends the user to `/set-username`. Reliable, latency-independent, affects only users with bad data.
• SSR timing (the ctrl-click case): on a server-side cold load the enrichment chain doesn't finish before the timer / the `.on` listener is the wrong primitive for a one-shot fetch, so the guard runs before the commit.

Fix

• `setUserInfo` now does an awaited `.once()` initial load and commits `userInfo` before the tier/voucher/patron enrichment, resolving only after that commit. The 1s `setTimeout` is removed; a live `.on()` listener is kept for ongoing updates.
• Tier resolution moved to a new guarded `enrichTier` action (`try/catch`), so a slow or failing patron lookup can never block or unset `userInfo` — affected users fall back to basic tier instead of breaking login.
• Route guards (`authenticated.vue`, `run-campaign.vue`, `Profile.vue`) redirect only when `userInfo` is loaded and has no username, distinguishing "still loading" from "no username".
• `SetUsername.vue` preFetch guards against an undefined `userInfo`.

Follow-up (data, not code)

If a user's login failure was caused by a corrupt `new_patrons` record, this stops it from breaking login but they'll silently get basic tier — inspect/repair that record separately.

Verification

• Ctrl-click deep link into a new tab while logged in → lands on the page, no console error
• Genuine new user (no username) → still routed to `/set-username`, can set it, lands on `/profile`
• Linked-Patreon account still resolves the correct tier after load

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud