refactor: make API registry authoritative

docs/governance/architecture-inventory.json

@@ -265,8 +265,8 @@
     },
     {
       "path": "server.py",
-      "bytes": 267824,
-      "lines": 5947
+      "bytes": 268422,
+      "lines": 5960
     },
     {
       "path": "static/redesign-v2.css",

docs/governance/stage-11-http-governance.md

@@ -0,0 +1,28 @@
+# Stage 11: HTTP Route, Access, and Error Governance
+
+Date: 2026-07-29
+
+## Result
+
+- Promoted `config/api.config.json` from a transitional inventory to the runtime route and
+  access registry.
+- Added deterministic exact and regex route resolution with duplicate and regex validation.
+- Replaced hand-maintained member/admin path sets with the registered access contract.
+- Rejected unregistered API routes before business dispatch.
+- Added safe request correlation IDs to JSON responses and `X-Request-ID` headers.
+- Extended every legacy JSON error with stable `code`, `message`, and `request_id` fields while
+  preserving the existing `error` field used by the browser.
+- Kept the current request handler and all route response bodies compatible while feature
+  route modules are migrated incrementally.
+
+## Runtime Authority
+
+Changing or adding an API now requires one coherent change to the handler and API registry.
+The generated source inventory test prevents either side from drifting. Backend access remains
+authoritative; frontend visibility cannot grant a route.
+
+## Residual Migration
+
+Individual dispatch branches still live in the compatibility request handler. Feature-owned
+controllers will move behind the same registry in later stages without changing route identity,
+authorization, or error serialization.