Guest sign-up: clear capacity and retry messages #260

Part of #86. Release: 0.8.0. Owner: Irzhy (@irzhywau). Anders (@andersalm) and Sasha (@SashaMIT) own product acceptance.

Selected policy

Retain the existing bounded guest-registration and passkey-start controls for 0.8.0, selected under Anders's current instruction to resolve this decision. Add only the capacity and retry behavior needed for the accepted signup journey. Cookie-based admission, proof-of-work and owner admission remain unselected.

Sasha's product acceptance, exact-candidate signup timing and saturation/recovery proof remain open. Keep this issue in QA / Review until those gates and any required correction are complete.

Exact current bounds

• 16 retained guest registration records per Home, including completed records until their original session expires after 12 hours. This is a retained-record cap, rather than 16 active challenges.
• Eight active guided registration challenges, expiring after five minutes. Ordinary registration and authentication have separate pools.
• Four starts per minute and eight per five minutes, separately for registration and authentication, keyed by Home and the observed socket IP. At most 256 Home/IP entries are retained. Cookies and forwarded headers cannot choose the quota.

Source: registration retention, completed records, challenge bounds, start admission.

A cookie can be cleared, so another cookie budget adds little protection beyond the existing bounded work. A stronger admission mechanism changes the product flow and needs a separate decision if later evidence justifies it.

Done means

• Anders records the selected bounded-control policy.
• Sasha accepts the selected policy and its first-use/recovery experience.
• A normal new account meets G3 Community chat: Chat and People with Home #86's 30-second acceptance on alpha.16.
• Saturation gives clear capacity and recovery behavior and preserves existing account completion/sign-in. The 16-record cap currently maps to 403 "owner enrollment unavailable"; give the person accurate capacity/recovery information and keep owner enrollment policy distinct.
• Retry behavior reflects both rolling budgets. The current 429 Retry-After: 60 does not establish that the five-minute budget clears after one minute; test recheck/recovery through that bound.
• Any correction passes the applicable refused cases, independent/human reviews and merge gate. Additional route/capability approval is needed only if its scope changes.
• Record measured installed signup, saturation and recovery results before closing.

Acceptance record

• Candidate and policy: the Chat candidate is recorded in #139. Both 16-record paths report typed guest capacity, and Retry-After uses the current rolling windows. The 16-record, eight-challenge, four-per-minute and eight-per-five-minute limits, owner policy and exact completion bypass remain unchanged.
• Source and integrated checks: independent source review and the guest quota, capacity, retry-window and completion regressions pass. The producer's standard gate and CI run 37876735825 pass. The consumer adds only the reviewed two-line People-tab test correction. #139 keeps the source/native reuse, artifact and complete canonical Mac 28/28 evidence; its journey report is 24c583b3332f82f36534af4cdcfded0967e3b920c70510cd86fb73c8bf6bef27.
• Installed rate and recovery: normal guest signup takes 1.082 seconds during 12 begin requests, with three admitted and nine refused. The next real window admits four starts; the ninth begin within 300 seconds returns Retry-After of 239 seconds. Normal UI recovery then completes signup in 0.488 seconds. These are real waits and normal controls. The unchanged rate report SHA-256 is 7217f5f2bbd6d24bfc408f7096f87dfdd247f3df52dbc6bddddffaa4f216d969.
• Installed retained-record capacity: the fresh capacity-only repeat passes all 16 normal guest signups, each in 322–608 ms, with real rolling-quota waits between batches. The full store presents typed 429 capacity feedback; Retry-After of 42,597 seconds matches the earliest original terminal expiry within two seconds. Exact adjacent auth bytes, registration/principal ownership and 37 protected files stay unchanged across the refusal. Replaying the first guest's exact completion returns its original principal and session with 16 records retained. That guest then signs in through the normal passkey control. Records receipt 1202340f8551a7b322de1b3f949df50dccf67c3a78308704936aacc8e0c9a159; lifecycle receipt 5fe60b2e4d0f6b3c811f7a0d31fe5486aa2b254f58c7ff92c9e70ceb3df9a688. All dedicated groups stop and are empty. The earlier assertion failure and its original 16-account fixture stay preserved; this result is the separate fresh capacity proof.
• Remaining acceptance and ownership: Interrupted records and the full pending-challenge limit still need installed proof on alpha.16. The shared-proxy case moves to Seed: run the seed service under its own account without sudo or Docker #174 while the public demo is paused. The PR #197 review records the shared proxy budget; visitors share that budget when Runtime sees one proxy socket address. Seed: run the seed service under its own account without sudo or Docker #174 owns flood/recovery acceptance before public demo reopening. Sasha retains policy and first-use/recovery acceptance; the final candidate needs required human review and merge. Chat and People: delivery states, Community catch-up and spam limits (follow-up to #86) #139 owns the new Community receipt repair and final combined-candidate qualification. This issue stays in QA / Review. Irzhy owns the signup controls, Anders owns the selected policy, and Sasha accepts the complete UX.