[kitamura-tetsuo]

Why this change is needed

The owner revised #24 to require only ChatGPT A to wake from a peer event, read the triggering message and reply. Claude Chat B can make manually prompted source posts. The current hosted runtime and protected release path permit only the paused manual profile, so the real A-host behavior cannot be measured.

This supporting PR adds a default-off, bounded staging verification profile. It is independent of the evidence tooling in #63. Keeping the implementation separate allows the protected deployment workflow to remain pinned to reviewed main while #63 retains its actual-host acceptance requirement.

What changes

• A single strict policy parser shared by runtime and Node release checks binds private-pilot-a-only to staging, exact build, A guest/connection, 1–3 synthetic tables, reviewed callback origin/path prefixes and a maximum two-hour window.
• Only the authorized A session advertises capabilities.events: {}. B keeps its existing authorized tools role. Public subscription/Events flags and public transport readiness remain disabled.
• Registration, callback verification and final durable dispatch recheck scope, time, connection authority and lifecycle. A reservation that crosses expiry is discarded before verification I/O. The canary accepts only events created in the window and message sequences up to 12; retained state preserves attempt budgets and prevents replay of accepted events.
• Existing native transport, Standard Webhooks signing, callback control, encryption, membership and durable retry checks remain in use. Expiry/outbound stop blocks new effects while preserving authorized reads and closure; restore quarantine remains separate.
• Protected staging deployment accepts the private profile only after exact-main CI, a fresh independent owner review, a policy-bound operations decision and live provider readback. Production stays manual; private activation cannot use bootstrap.
• Postverification binds exact config bytes and compares exact policy bytes in service settings and the active Worker version. Removed/orphan policy bindings and changed windows/stop settings fail verification.

Verification

• Typecheck and release-script Biome: passed in the isolated supporting worktree.
• All Node script tests: 109 passed in the combined working tree, including unchanged restore/runtime probes.
• Private policy + complete Events integration: 35 passed.
• Existing restore-quarantine integration: 11 passed.
• Independent runtime/release review: no outstanding actionable findings.
• The raw authenticated HTTP discovery response carries the provider Events capability; the generic SDK client's typed capability accessor strips the unknown extension, so the test checks the actual wire.
• Full GitHub verify CI: passed on exact head 480d37cb0cb49191c715f535171c3aa37803c8a2, including application/Worker/restore tests, subscription probes, OAuth mutation checks, Wrangler dry-runs and browser E2E. All 27 job steps succeeded.
• Final pre-merge check: no review submissions, no review threads and no merge conflict.

The published tree 41e58e8326b04ba84b5cac9d226c8f60c10206b2 matches the isolated staged source exactly.

Activation remains a separate decision

Refs #24; prepares #63. This PR does not close either live-evidence gate. No deployment, secret/DNS change, runtime flag activation or actual host wake-up result is included. Concrete A/B owner authorization, the actual A connection/tables/callback scope, exact candidate configuration and the protected staging approval are still required before the trial. The accepted #19 native-fetch residual trust assumption is retained; no new same-connection IP/TLS proof is claimed. Historical restore reconciliation in #51 is not conflated with the current-state no-restore restart.