feat(peer): async run/status with idempotent /v1/runs admission

[giaiant]

What

Adds peer async dispatch (Hermes peer run/status) with idempotent admission to the API server's /v1/runs endpoint.

• gateway/platforms/api_server.py: idempotent admission for /v1/runs — a lock serializes concurrent POSTs so the same idempotency key cannot create duplicate runs. The idempotency key is registered before the history read, closing the race where two same-key requests both pass the check and both create a run.
• hermes_cli/subcommands/peer.py: peer run / peer status subcommands.
• Tests: tests/gateway/test_api_server_runs.py + new concurrent same-key race test; tests/hermes_cli/test_peer_cmd.py.
• Docs: peer run/status + Idempotency-Key reference.

Why

Previously, the peer async work lived as an uncommitted diff. This promotes it to a reviewable change, and fixes a real race (idempotency key registered after the await, so concurrent same-key POSTs could double-create runs).

Test

• tests/gateway/test_api_server_runs.py + tests/hermes_cli/test_peer_cmd.py: 39 passed (incl. new race test)
• Regression tests/gateway/test_api_server.py + test_api_server_active_work_drain.py: 129 passed

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

Solid design overall: resolving a replay before the concurrency gate (gateway/platforms/api_server.py:6771-6774) is exactly right for lost-202 recovery, key validation bounds abuse, the idempotency map is swept in lockstep with status retention (api_server.py:7468-7472), and the lock makes check-and-register atomic against the history-reload await. Points:

1. The global admission lock is held across per-request session I/O — gateway/platforms/api_server.py:6695-6699 serializes all /v1/runs admissions, and the critical section now includes await self._conversation_history_for_session(...) (:6820-6823), which is disk/store I/O of unbounded duration per request. Every concurrent admission — including ones with no idempotency key at all — queues behind each other's history reloads, so p99 admission latency becomes the sum of in-flight history reads. Consider splitting into two short sections: fingerprint + replay-check under the lock, release for the history reload, then re-acquire only to re-validate the key and register the run. That keeps the atomicity that matters (key→run_id) without making unrelated admissions wait on one caller's store.

2. Replay responses are shaped differently from originals — originals return {"status": "started", "replayed": false} plus X-Hermes-Session-Key and other response headers (:7166-7170); replays return {"status": <live>, "replayed": true} with no headers (:6815-6821). A client that recovered from a lost 202 gets a subtly poorer response than the one it missed — most importantly the session-key header. Worth either attaching the stored run's headers or documenting the asymmetry in the endpoint docs you added.

3. Fingerprint coverage is an explicit allowlist — only input, session_id, instructions, conversation_history, previous_response_id, model, provider, model_options participate (:6790-6810). Two requests sharing a key but differing in any other semantic field (tool selection, metadata the run honors) silently replay the original instead of getting a 409. Defensible (stream-flag exclusion is actually correct), but the doc should list which fields are identity-bearing so callers don't assume whole-body semantics.

Tests covering the contended-wait race via _slow_history are exactly the right kind.

[dokterdok]

@giaiant I am using the async run/status commits as prerequisites in draft #95965 for an end-to-end RoomLink stack. Your commits and authorship are preserved unchanged; this is not intended to replace your PR. If this lands first, I will drop the patch-identical commits from the composition.