Test-User Factory

The factory exists for one reason: an operator should never QA a feature against a real user's data. Every spawned account lives in the isolated `sandbox-sys` tenant, which is documented and enumerated in `docs/tenants/sandbox-sys.md`. Operators open `sys/(dashboard)/sandbox`, pick a preset (`new player`, `club admin with pending approvals`, `federation admin with open incidents`, `retired player`, `suspended license`), or compose a bespoke configuration: role, language, nationality, license state (none / active / expired), club affiliation, 2FA state.

The endpoint provisions the user with the same hooks and validations as a real signup — there is no Cosmos shortcut — so tests reflect production behaviour. Sandbox screens are visually unmistakable: an amber header bar saying `SANDBOX — not real data` is rendered in admin and app whenever the tenant resolves to sandbox-sys, eliminating any chance of confusing it with a real federation. Outbound mail is intercepted at the transport layer: SendGrid sees a sandbox-tenant flag and reroutes everything to an internal catch-all inbox visible at `sys/(dashboard)/sandbox/mail-inbox`, so verification emails, OTP codes, password resets, and notifications can be inspected without ever hitting a real address.

When sandbox state needs to be wiped, `Nuke sandbox` cascades a delete across users, sessions, audit rows, and uploaded artefacts. The endpoint is throttled to once per hour and audit-logged, preventing accidental loops and giving the trail a clear `actor_id` for every wipe. The sibling `test-session` flow in F21.02 reuses the sandbox tenant when an operator wants to verify a feature in a specific role without spawning a long-lived account.