Rule on whether terra should restrict GoTrue signup to roster addresses, knowing that the open path is what lets a locked-out person report it

Raised out of TERRA-260. On 2026-10-01 37 GoTrue accounts were created in 7 minutes (12:27:51-12:34:47Z, against ONE in the whole 09-18..09-30 window); 28 matched a public.users row and bound, 9 did not. coder-enamel-cc calls the 9 an open-signup shape on terra's login surface and carried it here. Use 9 ACCOUNTS, not 13: 13 is the login:no-profile EVENT count in a 4-minute cut (19 events / 15 flowId over the full burst) and those rows carry no identity at all - actorUserId NULL, no email, no authId - so no headcount was ever measured, and two accounts can be one human. NOT A DEFECT, AND NOT A THING TERRA CODE CAN CHANGE. The membership gate held: the 9 received no terra access. findAppUserByAuthId is strict sub-anchored with no email axis on any read path (src/lib/auth.ts:77-91 - a fallback there was removed precisely because it granted a session the roles of whatever row shared the address, unobservably), and terra holds zero writes to users or userGroups. login-card.tsx:142 is signInWithOAuth({provider:'google'}), so who may create a GoTrue account is a Supabase project/provider setting, not terra source. THE DECISION, and it is a tradeoff rather than a fix: the shape is deliberate. A non-roster person signs in, lands on no-profile, and that SESSION is what lets them file an access report - reportAccessIssue refuses without one (access-issue-actions.ts:63-69), and the refusal landing renders without a session by design so it does not loop the one population that has just shown login is not their problem. Restricting signup removes the channel that produced ceda0a10, e40c64e2 and 1732f5cb, and the 10 burst accounts that never reported would lose the only route they still have. Needs Elazar. Not actioning either way.