fix(agent): detect SOUL.md drift on session restore via the shared identity resolver

[Sora-bluesky]

What changed

This PR no longer rebuilds the system prompt when it detects SOUL.md drift during session restore. agent/conversation_loop.py is back to the main behavior (the three restore-path hunks from the original commit are reverted, net diff zero).

Identity drift detection moved to the one place AGENTS.md:19-23 already allows the system prompt to change: the Hermes-native compaction keep-prompt gate in agent/conversation_compression.py. That gate used to keep the cached prompt whenever built-in memory state matched. It now also checks stored_identity_is_stale() and falls through to a full rebuild when the identity block no longer matches what's on disk. The rebuilt prompt gets persisted the same way any other compaction-time prompt already does: update_system_prompt writes it directly when compaction runs in place, and publish_compression_child carries it along when compaction rotates to a new session id.

One related fix: resolve_identity_block() in agent/system_prompt.py treated a missing HERMES_HOME directory the same as a HERMES_HOME that exists but has no SOUL.md in it, both landing on checkable=True and a default identity. Those are different failure modes. If HERMES_HOME itself isn't there, we can't say anything meaningful about identity, so that case now reports checkable=False and the staleness check fails open (no rebuild) rather than confidently concluding "identity is default."

Why not fix it at restore time

The original approach rebuilt the prompt inside _restore_or_build_system_prompt, which runs whenever agent._cached_system_prompt is unset (agent/turn_context.py:613-615). AGENTS.md:19-23 states the system prompt is never rebuilt mid-conversation except for the compression exception, because doing so busts prompt caching and multiplies request cost. Restore isn't that exception; compaction is.

Limitation: sessions running the app-server runtime

Sessions using api_mode == "codex_app_server" take a different compaction path (_compress_context_via_codex_app_server), and that path has no system-prompt write-back at all, on main or in this PR. Adding a staleness check there wouldn't do anything, because Hermes never transports a system prompt to a CAS session in the first place, new or existing: the app-server turn path skips active_system_prompt entirely (agent/conversation_loop.py:1249-1256), CodexAppServerSession.__init__ (agent/transports/codex_app_server_session.py:274-311) takes no prompt argument, and the per-turn call (agent/codex_runtime.py:698, run_turn(user_input=...)) sends only the user's message. This PR leaves that path untouched. If you're running against the app-server runtime, editing SOUL.md has no effect on the session through Hermes at all; prompt delivery for that runtime is a separate gap, out of scope here.

About issue #68563

The issue asks for SOUL.md edits to reach a running session right away. What this PR delivers is narrower: on the default (non-app-server) configuration, an edit reaches the session at the next Hermes-native compaction, not immediately, and it's persisted to the database when it does. Immediate reflection is a different feature: AGENTS.md:19-23 disallows rebuilding the system prompt mid-conversation outside the compression exception, so restore was never a place this could live. Getting from "eventually, at compaction" to "on demand" needs a command a user invokes on purpose, so the cost of rebuilding is one they choose to pay rather than one that fires on every turn regardless of the input file.

Two things could be split out as follow-ups, out of scope here:

1. An explicit reload command (something like /reload-soul) as a real answer to "I want this applied now."
2. Actual prompt delivery to CAS sessions, so identity drift could eventually reach sessions running that runtime too. Write-back alone wouldn't be enough: Hermes would also need a way to send a system prompt into a CAS session at all, which nothing in the codebase does today.

Neither is part of this PR. #68563 itself stays open for the maintainers to judge.

Testing

• TestPromptStabilityInvariant and two new restore-path pins confirm identity drift never touches the cached prompt or calls update_system_prompt during restore.
• TestIdentityStalenessRebuild's scenarios (edited, truncated, and deleted SOUL.md) now assert verbatim reuse on restore instead of rebuild, matching the behavior above.
• New compaction-gate tests cover both directions: the keep optimization still holds when identity is unchanged, and it's suppressed (with persistence) when SOUL.md changed.
• New pins confirm the app-server path and the live-child-adoption path both keep passing the cached prompt through unchanged, even with drift present, which documents the current limitation rather than silently relying on it.
• TestSessionStartHookGuard moved out of this file; it belongs to a separate PR fixing the on_session_start double-fire bug, which is a pre-existing issue unrelated to SOUL.md identity.

[teknium1]

Thanks for the focused SOUL.md fix. The current-main premise is real: agent/conversation_loop.py:470 restores a stored prompt after _stored_prompt_matches_runtime(), whose checks end at model/provider/cwd/platform in agent/conversation_loop.py:604-632; SOUL.md is loaded into the stable identity slot in agent/system_prompt.py:189-201.

Problems

• The linked issue's requested contract is broader than this patch. agent/prompt_builder.py:2169-2175 also loads managed project context from .hermes.md/HERMES.md, AGENTS.md, CLAUDE.md, or .cursorrules; changes there still leave the persisted prompt reusable. The Gateway durable sessions do not refresh system prompt after SOUL.md changes #68563 discussion explicitly distinguishes this PR as SOUL-only.
• Because the PR body says Fixes #68563, it could close the broader fingerprint issue despite not implementing its durable paired-persistence requirement.

Suggested changes

• Either extend this into the managed-input fingerprint contract, including every prompt-snapshot write path, or re-scope it as a SOUL.md-only partial fix and remove the closing issue reference.

Automated hermes-sweeper review.

[Sora-bluesky]

The header is fixed. The body's first line now reads Refs #68563. and no closing keyword remains anywhere in the body, so merging this will not auto-close the issue. The scope note stands: this PR covers the SOUL.md identity slot only, and the persisted fingerprint contract for the other managed inputs stays with #68563.

[Sora-bluesky]

Rebased onto current main (30fcf95) as a single commit (4980347b, was 3 commits ending at 6f8132a6). Upstream had landed the Bot Chat capability-epoch block in agent/conversation_loop.py exactly where the first commit of this branch used to touch it; since the second commit had already moved the drift check to the compaction boundary, the net diff never touched that file, so I applied the net diff on top of main instead of replaying the intermediate step. The +/- lines are unchanged (3 files: agent/system_prompt.py, agent/conversation_compression.py, tests/agent/test_system_prompt_restore.py); the three commit messages are folded into the new one. tests/agent/test_system_prompt_restore.py 37 passed on the rebased tree. Still waiting on the #68563 decision — no action needed on that front.