Add shared upstream DMG acceptance gate

[ilysenko]

Summary

• add one acceptance engine and release profile shared by local installs, rebuilds, the updater, and GitHub Actions
• evaluate only Linux Features enabled by the user and preserve the working app if any enabled feature drifts
• make candidate promotion interruption-safe with atomic directory exchange, a durable recovery journal, backup, and rollback
• prevent automated user-local updates from bypassing the running-app or acceptance gates
• retain exactly one managed previous-app backup and prune older read-only copies safely under the promotion lock
• publish updater downloads to leased, content-addressed paths and bound cleanup to the state-referenced DMG
• reconcile only automation-owned drift issues with valid fingerprint markers and fail-closed HTTP identity checks

Why

Local installation and CI previously evaluated upstream drift through separate paths, and the normal install flow could overwrite the working app before late checks completed. The earlier transactional swap also left a two-rename interruption window, while updater caches and app backups could grow without bounds. Automated user-local rebuilds additionally forced a developer override that permitted replacing a running Electron runtime.

This change makes reports and policy the single source of truth, keeps the canonical install path continuously available, refuses automated promotion while the installed app is running, and retains only the immediately previous working app. Disabled Linux Features are not probed; drift in a user-enabled feature rejects the candidate until the user disables or repairs that feature.

Prior work and ideas

This PR consolidates or responds to ideas from:

• #737 for structured upstream release decisions and diagnostics; the intelligence report remains optional evidence while shared patch reports own acceptance
• #810 for scheduled upstream issue automation; issue identity uses DMG SHA-256 with supersede, reopen, stale-run, missing-identity, and ownership-marker handling
• #787 for safe updater downloads and streamed hashing; publication uses immutable content-addressed paths, syncs the file and parent directory, and protects consumers with cache leases
• #815 as design input around automatic drift handling; this PR deliberately chooses deterministic report-based acceptance instead of content-scan fallback paths

Thanks to @joshyorko, @avifenesh, and @ryan-mt for the investigation and proposals that informed this design.

Checks

• shell and Python syntax checks
• acceptance, issue lifecycle, updater-hook, and upstream intelligence tests: 48 passing
• patcher tests: 364 passing
• full scripts smoke suite, including running-app refusal, bounded backup retention, read-only cleanup, SIGKILL recovery, package payloads, promotion locking, and managed Node
• cargo fmt --check, cargo check, and all 235 updater tests
• ci-local core reaches the unchanged Computer Use runtime fixture; that local container fixture cannot resolve its required app-server manifest path, while all affected updater, shell, Node, and packaging suites pass

Notes

• updater version is bumped to 0.9.4
• automated user-local paths force CODEX_INSTALL_ALLOW_RUNNING=0 and CODEX_ACCEPTANCE_OVERRIDE=0; the direct installer retains an explicit developer-only running-app override
• Nix and the real current-DMG acceptance build are verified by required GitHub checks

[joshyorko]

@avifenesh I like this. I’m going to set something up, but we should borrow from "OpenClaw" (https://github.com/openclaw/openclaw/blob/main/CONTRIBUTING.md) before PRs pile up. Their rules welcome agent work but demand scope, evidence, and accountability. Steinie’s "transcript skill" (https://github.com/openclaw/openclaw/blob/main/.agents/skills/agent-transcript/SKILL.md) is smart too: opt-in, redacted, and focused on intent and proof—not raw chats.

Jorge Castro is taking "Project Bluefin" (https://docs.projectbluefin.io/agentic-contributing/) further: agent instructions, scoped skills, an agent-ready queue, "/claim", human gates, and attribution. The repo itself tells agents how to work in it.

We should not copy either whole. But #834 gives us the right base. A small follow-up could make this repo agent-ready.

It would also send OpenAI a clear signal: we are not just bringing Codex to Linux. We are building it with Codex, in the open. At least we tried