ACP session/resume replays history despite advertising resume capability

Summary

Hermes advertises ACP session/resume, but the implementation currently replays session history before returning the resume response. Current ACP session semantics distinguish session/load from session/resume: load restores a session for display and replays history, while resume should reattach/continue without replaying prior transcript updates.

This makes Hermes' advertised resume capability behave like load, which can cause ACP clients to duplicate or re-render transcript history when they expected a no-history resume path.

Evidence

• Hermes advertises resume support from ACP initialization:
  • acp_adapter/server.py initialize(...) returns SessionCapabilities(... resume=SessionResumeCapabilities()).
• session/load correctly replays history before responding:
  • acp_adapter/server.py load_session(...) calls _replay_session_history(state) before returning.
• session/resume currently does the same replay:
  • acp_adapter/server.py resume_session(...) calls _replay_session_history(state) before returning.
• Existing tests lock in that behavior:
  • tests/acp/test_server.py has test_resume_session_replays_history_before_returning_response.
• The ACP dependency is currently pinned to agent-client-protocol==0.9.0, while ACP docs/protocol text now specify different load vs resume replay behavior.

Expected Behavior

session/resume should not emit prior history/session updates before its response. If Hermes wants to support ACP resume, it should restore the session's runtime state and return the normal resume response without replaying the transcript.

session/load should continue to replay history for clients that need to reconstruct/display the transcript.

Actual Behavior

resume_session(...) replays history via _replay_session_history(state), so ACP clients receive the historical session/update stream before the resume response, matching load-like behavior.

Why this matters

Clients and muxes can use session/load and session/resume for different UX/lifecycle flows:

• load: hydrate a transcript/history view.
• resume: reattach or continue a session where replay is not desired.

If Hermes advertises both but implements both with replay, clients cannot rely on the advertised capability split. That can lead to duplicated transcript content, stale rendered turns, or unnecessary replay traffic.

Proposed Fix

Choose one of these narrow fixes:

1. Preferable: change resume_session(...) so it restores session state but does not call _replay_session_history(state).
2. If Hermes cannot safely provide no-replay resume semantics yet: stop advertising sessionCapabilities.resume until it can.

Then update tests so they encode the protocol distinction instead of current load-like resume behavior.

Acceptance Criteria

• session/load still replays prior history before returning.
• session/resume does not replay prior history before returning.
• Initialization only advertises sessionCapabilities.resume when Hermes provides no-replay resume semantics.
• A regression test asserts that resume_session sends no historical session/update replay before the response.
• Existing load/fork/list behavior remains unchanged.

Notes / related context

This was found during a read-only ACP implementation audit. No code changes were made as part of the audit.

Related ACP evolution to keep in mind while touching this area:

• ACP has active session-lifecycle work around attach/status/inject/runtime context and additional session fields.
• Hermes currently pins agent-client-protocol==0.9.0; any SDK bump should separately test lifecycle request fields and advertised capabilities.