#28211 acpmux: add opt-in managed Codex runtime

Adds the first opt-in managed Codex runtime slice for NEXT. Harnesses can explicitly run cmux harness codex-runtime install or status; the installer downloads the official v0.156.1 macOS archive, verifies the SHA-256 pinned beside the Codex harness manifest, stages and atomically activates a versioned binary under acpmux support storage, and discovery falls back to it only when no codex is on PATH. Existing profiles and PATH installations remain authoritative.

Prior art reviewed: #26333 (harness fixtures), #21568 (selected installation remains stable during Bun updates), #21439 (trusted Settings agent updates), and #3624 (cmux harness add/list/doctor/reload). Nearby Codex PRs #24428, #24490, #21278, #856, #4048, #18302 and #26106 do not bundle or manage a Codex runtime.

This slice deliberately excludes app bundling, signing/notarization, update/removal, and profile migration; those follow-up concerns need release packaging work.

Agent-Session: deeplink/agent?id=aid-eb216cbafc54de38a870

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Adds an opt-in managed Codex runtime for acpmux. cmux harness codex-runtime install downloads the official Codex v0.156.1 macOS archive, verifies its SHA-256 against the hashes pinned in the Codex harness manifest, and atomically activates it by swapping a current symlink with one rename, so the runtime path stays valid at every instant and a crash leaves either the old or the new install. A successful install tells a running daemon to read its profiles again, and cmux harness codex-runtime status prints the runtime state. Activation is Unix-only, and install directories are pruned only when nothing names them and they are over an hour old, so a concurrent install is never removed mid-swap.

The managed binary is used only when a readiness marker records the same pinned version and archive hash, so an interrupted or stale install never activates. It never overrides a codex already on PATH, so existing PATH installations, profiles, and explicit configuration stay authoritative. App bundling, signing/notarization, update/removal, and profile migration are deliberately excluded and will follow in release packaging work.