Persist Codex threads across Hermes sessions

[linsipeng]

What changed

• persist the Hermes session to Codex thread ID mapping in the profile-aware Hermes home
• resume an existing App Server thread after the Hermes runtime client is recreated
• keep new threads on the existing thread/start path
• add lifecycle and persistence tests
• document the Hermes × Codex Desktop shared-thread architecture, use cases, boundaries, and roadmap

Why

Hermes previously kept the Codex thread ID only in memory. If Hermes restarted or retired its App Server client, the next turn created a new Codex thread. That split task history and prevented reliable handoff between Hermes and Codex Desktop.

Using the exact persisted thread ID lets both surfaces continue the same Codex task without title matching or prompt copying.

User impact

Hermes sessions using the optional codex_app_server runtime can recover their existing Codex task after process recreation. The same task can be opened in Codex Desktop for inspection or manual continuation and later resumed by Hermes.

Validation

• 95 focused tests passed:
  • tests/agent/test_codex_thread_store.py
  • tests/agent/transports/test_codex_app_server_session.py
  • tests/run_agent/test_codex_app_server_integration.py
• live compatibility probe verified thread/start, turn/start, thread/read, Codex Desktop navigation, and thread/resume on codex-cli 0.144.1

[alt-glitch]

This was generated by AI during triage.

Related to #41905: both preserve Codex App Server continuity, but this PR uses a profile-home session-to-thread mapping rather than #41905's gateway SessionStore path. Please consider consolidating the persistence owner and reset semantics.

[linsipeng]

Closing at the author's request; the fork and published branch are being removed.