Scope Responses API conversation names by session key

[necoweb3]

Summary

This scopes Responses API conversation chaining to X-Hermes-Session-Key when the header is present. Previously, conversation names were global, so two different clients using the same conversation name could chain into each other's stored response history.

Why

X-Hermes-Session-Key is the long-term memory boundary. If two clients use the same conversation name under different keys, the server should keep those chains isolated instead of reusing the latest response ID from another key.

Changes

• Namespace the stored conversation lookup key with the active session key when present.
• Preserve the existing global behavior for callers that do not send a session key.
• Add a regression test proving the same conversation name stays isolated across two different session keys.

Tests

python -m pytest tests/gateway/test_api_server.py -k "conversation_names_are_scoped_by_session_key or separate_conversations_are_isolated or conversation_chains_automatically" -q
3 passed, 155 deselected, 3 warnings in 2.49s

[teknium1]

Thanks for identifying the Responses API isolation gap. The API premise is confirmed on current main: named conversations are looked up globally at gateway/platforms/api_server.py:3277 and persisted globally at gateway/platforms/api_server.py:3520; the streaming snapshot path has the same behavior at gateway/platforms/api_server.py:2767.

Problems

• The bundled webhook retry cleanup cannot observe real agent-run failures. Its callback watches the task that awaits handle_message (gateway/platforms/webhook.py:675 in this PR), but current handle_message is fire-and-forget (gateway/platforms/base.py:4608-4615). Actual processing failures are reported through on_processing_complete (gateway/platforms/base.py:5174-5180, 5226-5235). The added test mocks handle_message itself (tests/gateway/test_webhook_adapter.py:642), so it does not exercise that lifecycle.

Suggested changes

• Please split or remove the unrelated webhook commits from this API-scoping PR.
• For a separate webhook fix, clear failed delivery IDs from on_processing_complete based on its failure outcome and test the real background pipeline.

Automated hermes-sweeper review.

[teknium1]

handle_message() is fire-and-forget: it schedules _process_message_background and returns, so this task normally succeeds even when the actual agent run later fails. Release this ID from the existing on_processing_complete lifecycle hook using its failure outcome; the current test hides the issue by mocking handle_message itself.