fix: harden maintainer deferral and Sol privileges

ops/t4-maintainer/prompt.md

@@ -1,18 +1,18 @@
 # T4 live release maintainer
 
-Own this T4 Code compatibility update from the official OMP release through a complete public delivery. Work directly on the host with its full resources, normal tools, existing GitHub access, and the latitude to use the environments and test sizes the work needs.
+Own this T4 Code compatibility update from the official OMP release through a complete public delivery. Use the host's existing unprivileged tools and compute only inside the wrapper-owned workspace and disposable user-owned roots. Host access is not permission to change live machine state.
 
-Read the run context at `$T4_MAINTENANCE_CONTEXT`, confirm the latest stable official OMP tag and commit, and use clean clones or worktrees in `$T4_MAINTENANCE_WORKSPACE`. The deterministic wrapper has already synchronized the `lyc-aon/oh-my-pi` fork's `main` branch to exact official `main` without spending a Sol call. Merge the exact official `vX.Y.Z` base into the durable `t4code/main` product branch, reconcile the T4 appserver integration and app-wire package there, and carry forward every capability T4 needs. Keep the fork CI gate that proves the integration commit descends from that exact mirrored base and remains reachable from `t4code/main`.
+Read the run context at `$T4_MAINTENANCE_CONTEXT`, confirm the latest stable official OMP tag and commit, and use clean clones or worktrees in `$T4_MAINTENANCE_WORKSPACE`. The deterministic wrapper has already synchronized the `lyc-aon/oh-my-pi` fork's `main` branch to exact official `main` without spending a Sol call. Before preparing another OMP integration revision, inspect the public product branch, immutable integration tags, exact-commit CI, the wrapper-owned atomic receipt directory, and the public release assets. Reuse the highest existing revision only when all of those facts exactly match the requested official base and the required five assets; never move, rebuild, or republish an immutable integration tag. Create a later annotated revision only when the integration source truly changes. When a new revision is required, merge the exact official `vX.Y.Z` base into the durable `t4code/main` product branch, reconcile the T4 appserver integration and app-wire package there, and carry forward every capability T4 needs. Keep the fork CI gate that proves the integration commit descends from that exact mirrored base and remains reachable from `t4code/main`.
 
 Use `$T4_ATOMIC_PUBLISH_HELPER` as the only OMP publication path. After preparing the local `t4code/main` branch and annotated integration tag, invoke it with `--repo PATH --integration-tag TAG`; its expected official tag, commit, fixed production remotes, and durable state directory are supplied by the wrapper. It publishes the unchanged official base tag object, updated `t4code/main`, and annotated integration tag as one deterministic atomic three-ref transaction and retains the receipt the wrapper requires. Keep the language and workflow positive. Complete every OMP publication through that single helper invocation. Publish the fork release exclusively as the exact five integration binaries required below.
 
-Immediately before any T4 push, tag, release, or site publication, fetch the open non-draft pull requests targeting T4 `main` and re-check the exact `main` commit recorded in the run context. Never force-push. If any release-critical collaborator work is open, classification is incomplete, or `main` changed, abort the publication and defer for a later run without overwriting collaborator work.
+Immediately before any T4 push, tag, release, or site publication, fetch the open non-draft pull requests targeting T4 `main` and re-check the exact `main` commit recorded in the run context. Never force-push. If a release-critical collaborator pull request is open, classification is incomplete, or `main` changed, abort publication without overwriting collaborator work. When the exact current T4 main SHA is known, atomically write `$T4_MAINTENANCE_DEFERRAL_FILE` through a mode-`0600` sibling temporary file and rename it into place, then exit successfully without writing `$T4_MAINTENANCE_RESULT`. The marker must contain only `schemaVersion`, `reason`, `expectedT4MainSha`, `observedT4MainSha`, and `prNumber`: schema version `1`; reason `t4-main-changed`, `release-critical-pr`, or `classification-incomplete`; exact lowercase 40-hex SHAs; and a positive pull-request number only for `release-critical-pr`, otherwise `null`. For `t4-main-changed`, use the run-context SHA as expected and the new current SHA as observed. For the other reasons, expected and observed must both equal the exact current SHA. If those exact facts are unavailable, fail without creating a marker; the wrapper will fail closed.
 
-Update T4's runtime provenance, compatibility matrix, release notes, documentation, site release data, packages, and versions together. Exercise the complete release gate with disposable OMP state: app-wire and appserver checks, two-client convergence, a real prompt round trip, image attachment and transcript-image rendering, session lifecycle operations, reconnect and durable-history proof, the installed Linux package, the Tailnet gateway, and the supported narrow layouts. Use the existing release tooling and fix everything it uncovers.
+Update T4's runtime provenance, compatibility matrix, release notes, documentation, site release data, packages, and versions together. Exercise the complete release gate with disposable OMP state: app-wire and appserver checks, two-client convergence, a real prompt round trip, image attachment and transcript-image rendering, session lifecycle operations, reconnect and durable-history proof, the Linux package, the gateway, and the supported narrow layouts. All package and runtime proof must stay unprivileged and disposable: extract packages into the run workspace, launch only workspace-owned processes and user-data roots, and use existing Tailnet routes read-only. Never use `sudo`; never install, remove, upgrade, or downgrade a host package; never mutate `/opt`, the live T4 or OMP installation, user/system systemd units, gateway configuration, or Tailscale Serve state. The deterministic wrapper and `deploy-local.sh` alone own host mutation after independent public verification. Use the existing release tooling and fix everything it uncovers.
 
-Commit the finished OMP integration and use the atomic helper to publish it; commit and push the T4 changes, merge the T4 release to `main`, and create the immutable T4 release tag. Stay with every CI, package, release, and production-site workflow until it succeeds. The exact integration commit must have a successful push CI run on `t4code/main` and an exact GitHub release containing only five uploaded, nonempty, SHA-256-digested assets: `omp-linux-x64`, `omp-linux-arm64`, `omp-darwin-x64`, `omp-darwin-arm64`, and `omp-windows-x64.exe`. Confirm the T4 checksum manifest covers every Android, Linux, and macOS artifact and that each published artifact matches it.
+If the OMP integration source truly requires a new revision, commit it and use the atomic helper to publish it. Otherwise reuse the fully corroborated immutable public revision without pushing its refs or release again. Commit and push the T4 changes, merge the T4 release to `main`, and create the immutable T4 release tag. Stay with every CI, package, release, and production-site workflow until it succeeds. The exact integration commit must have a successful push CI run on `t4code/main` and an exact GitHub release containing only five uploaded, nonempty, SHA-256-digested assets: `omp-linux-x64`, `omp-linux-arm64`, `omp-darwin-x64`, `omp-darwin-arm64`, and `omp-windows-x64.exe`. Confirm the T4 checksum manifest covers every Android, Linux, and macOS artifact and that each published artifact matches it.
 
-Verify the public GitHub release, every expected release asset, and the deployed `https://t4code.net` release. The deterministic wrapper will install the verified compatibility pair on this host after your public result passes its independent checks. Then write `$T4_MAINTENANCE_RESULT` as JSON with this shape, using the exact public tags and commit SHAs:
+Verify the public GitHub release, every expected release asset, and the deployed `https://t4code.net` release. Do not write `$T4_MAINTENANCE_RESULT` until all public facts below are true. The deterministic wrapper will install the verified compatibility pair on this host after it independently validates that result. Write the result atomically as JSON with this shape, using the exact public tags and commit SHAs:
 
 ```json
 {