git:20260902.10f5eb0 to git:20260903.ce3778d

+ - Keep the checked-in Vercel build command bound to exact non-secret marker `WRENCH_VERCEL_BUILD=release-bound-v1`, Vercel System Environment Variables enabled, and the Production Branch configured as `website-production`. Local admission is allowed only when the marker and every Vercel signal are absent. A marked or otherwise Vercel-signaled build must have the exact marker, `VERCEL=1`, a valid `VERCEL_ENV`, and an exact nonempty `VERCEL_GIT_COMMIT_REF`; missing, malformed, or inconsistent state fails before verification or building. Require `VERCEL_GIT_COMMIT_REF=website-production` only for production, and reject that ref for a non-production deployment. Vercel requires the branch to exist before configuration, so `docs/publishing.md` permits one initial create-ref at the exact current immutable Latest Release commit. After that one-time bootstrap, the tag Release workflow may only create or verify the immutable Latest Release. A separate workflow loaded from exact current `main` owns production promotion. It must bind the Release `workflow_run` or manual recovery to exact current main and immutable release authority, snapshot the complete bounded provider baseline before any key admission, keep already-exact recovery entirely outside the key environment, and use the dedicated one-repository release App only for a required fast-forward. The key environment must set `deployment: false`; the App and each minted token must have exactly `metadata:read`, `contents:write`, and `workflows:write`; every read-only GitHub child must be scrubbed of App values; and the writer must use a private askpass token to fetch only the verified tag, locally require its peeled commit to equal the independently verified release SHA without executing tagged code, and perform the one write with an explicit expected-old `--force-with-lease`. After that operation, the shared helper must send exactly one empty-204 token revocation with a canonical GitHub `Date` strictly before the minted `expires_at`, then observe the exact Wrench installation-repository endpoint at the reviewed ten absolute offsets inside a 30-second half-open request-start window. Every accepted 200 or 401 also requires a canonical pre-expiry `Date`. Two stable HTTP 401 observations must converge before the exact ref readback; `propagationObserved=false` means those were the first two probes with no observed 200, while `true` means at least one exact 200 preceded the final two 401s. A 401 followed by 200, nonconvergence, indeterminate transport or timing, redirect, malformed response, or after-deadline completion fails closed. The window is an operational ceiling, not a GitHub propagation SLA, and the action is never retried. A missing branch is a hard failure, and neither workflow may create, delete, force-move, or accept divergence. A separate 30-minute read-only job must use one injected monotonic 20-minute `[start, deadline)` provider window for absolute observation slots at minute offsets zero through 19, leave separate orchestration headroom, charge API latency without sliding those slots, fingerprint the complete current state and `latestStatus` of at most 500 Production deployments, exhaustively audit the pinned candidate's REST status history, reject every retained failure, error, or inactive row, bind the REST deployment's exact commit ref and SHA to GraphQL's null ref and matching commit OID, bind the GraphQL and REST current-status identities, and finish after the initial success observation plus two stable tag, immutable Release, Latest Release, workflow-source, ref, inventory, and status authority readbacks before promotion succeeds. The global receipt must not depend on previous deployment statuses that GitHub deletes after 90 days; GitHub preserves the current status on the deployment. Live lifecycle rules cover creation, deletion, and non-fast-forward movement on production and canary. A separate update rule denies every updater except exact App `4783991` as an `Integration` with `bypass_mode=always`; the retained canary evidence proves that boundary. Production-only freeze ruleset `22149969` must continue to block every production update until a fresh release-owner audit removes it by captured numeric ID. Treat `main` and pull-request deployments as previews. Production builds must verify external release state before reading release identity and provider capabilities from their exact checked-out tag commit; preview builds must not depend on npm or GitHub release availability.

+ - Keep the App and minted token permission set exact at `metadata:read`, `contents:write`, and `workflows:write`. Workflows write is required because an admitted fast-forward may introduce reviewed `.github/workflows` changes. Runtime must narrow and validate the minted token for Wrench, while privileged setup separately proves that the installation-wide selected-repository set contains only Wrench. Keep Administration and every other permission forbidden. Require the sole-reviewer key environment to use reviewer `0thernet`, `prevent_self_review=false`, no administrator bypass, exact `main` admission, and `deployment: false`. The retained admission proof is workflow run `33691443614`: an ordinary update was denied, the dedicated App performed the only leased `P` to `C` fast-forward on persistent ref `refs/heads/website-production-canary`, the stale lease was rejected, and revocation converged to two stable authorization denials. Keep that ref at exact `C=0bf88a064233635e0c5485c61f9c533974a7dca4`, never reset, delete, or repurpose it, keep the single-use canary source removed, and keep the production helper hard-bound to `website-production`.