feat(operations): add capacity and resilience gates (#18)

docs/architecture/0003-state-privacy-availability-and-budgets.md

@@ -129,9 +129,18 @@ until the owner records:
 - which games may enable anonymous unlisted player hosting;
 - deployment regions, data-processing jurisdiction, and approval of the stated
   30-day audit/13-month aggregate retention periods;
-- the per-game dedicated fallback endpoint policy;
-- the measured supported profile and whether the 99.5% single-active objective
-  is sufficient or shared-state/high-availability work must be brought forward.
+- the per-game dedicated fallback endpoint policy.
+
+Issue #18 measured and ratified the original 2-vCPU/2-GiB, 25,000-listing,
+10,000-attempt core-state candidate profile and retained the 99.5% single-active
+topology. It does not claim that core measurements prove public HTTP/UDP SLOs.
+The versioned evidence, RTO, failure domains, and explicit signals that trigger
+shared-state/high-availability work are recorded in the
+[capacity and resilience gate](../operations/capacity-and-resilience.md). The
+real-network canary in #23 must confirm that the proposed regional launch load
+fits this profile and validate the public SLOs; it may lower the launch cap but
+may not silently enable a
+second active instance.
 
 These are configuration and launch decisions, not permission to weaken the
 tenant, replay, endpoint-verification, or secret-handling controls.