fix(codex): keep the Stop hook out of user-level Codex config; report a read-only .codex

[ChronodeAi]

Two problems in the Codex Stop hook install, both found while deploying --target codex on a machine whose home directory is already a hyperresearch project. In that setup the Claude-side bootstrap had already run from ~.

1. Home-directory vaults turned the stop gate into a user-level hook. _install_codex_stop_hook writes <vault_root>/.codex/hooks.json. When vault_root is ~, that path is Codex's user-level hooks file, so the gate ran in every Codex session. run stop-gate finds a vault by walking up from the session's directory. So while a home-vault run was mid-pipeline (including a run driven from Claude Code), unrelated Codex sessions anywhere under ~ were force-continued with "continue the hyperresearch run" prompts. The docstring already says "never ~/.codex", and the global install already avoids it. The hook is now skipped with a "NOT installed" note whenever the project's .codex/ resolves to $CODEX_HOME (default ~/.codex).

2. The first-run bootstrap crashed inside the Codex sandbox. The workspace-write sandbox keeps .codex/ read-only, even when the directory does not exist yet. So install --steps-only . --target codex, run by the entry skill's step 0, wrote the step files and then died with OSError: [Errno 30] Read-only file system. Reproduced with codex sandbox -c sandbox_mode="workspace-write" -- hyperresearch install --steps-only . --target codex. It now returns "NOT installed" together with the command to run outside the sandbox, the same way it already handles an unparseable hooks.json. The Codex entry skill tells the orchestrator to re-run that one command once with escalated permissions, and to carry on without the hook if escalation is unavailable (codex exec).

Tests: two regression tests. One sets the home directory through both CODEX_HOME and HOME; the other makes .codex read-only. Both fail before this change and pass after. Full suite: 1722 passed.