docs(turn-loop): facts + structure pass

Frame the turn loop runtime-neutrally: every turn runs through
hive-runtime, on claude (default) or an ACP agent. The loop steps,
harness binary shape and hive-agent README now say so; claude-only
failure detection gets its own heading; claude-invocation.md opens with
its scope and links the ACP side to hive-runtime/README.md.

Fact fixes: on-boot file paths (/run/hive-config, not /run/hive),
hive-claude is a crates.io dependency with no README here, hive-agent
has no client.rs or forge_notify.rs, the claude launch-config layer is
hive-agent's mcp_config.rs, agent forge/matrix accounts are
swarm-controller's, hive-c0re's dashboard is dashboard/, and the
deprecated hyperhive.gui.enable / hyperhive.extraMcpServers spellings.

Refs #3902

hive-agent/README.md

@@ -1,8 +1,9 @@
 # hive-agent
 
 The in-container harness serve-loop binary — one instance per agent.
-Long-polls the broker inbox and drives one `claude --print` turn per
-inbox message, over the `hive-claude` driver. There is one role here
+Long-polls the broker inbox and drives one turn per inbox message
+through `hive-runtime`, on the agent's runtime (`claude --print` by
+default, or an ACP agent). It has one role
 (agent); the `Surface` trait + `AgentSurface` zero-sized type tag keep
 the turn loop generic and testable for future roles without a
 parallel copy of the loop.
@@ -11,20 +12,21 @@ parallel copy of the loop.
 
 You don't call into this crate from elsewhere — it's the top-level
 binary systemd starts per agent container. Look here when you need to
-understand or change: what happens between "a message lands in the
-inbox" and "claude produces a reply", how login/auth is bootstrapped,
-how the per-agent web UI is served, or how turn/event stats get
+understand or change: what happens between a message landing in the
+inbox and the agent's reply, how the harness bootstraps login/auth,
+how it serves the per-agent web UI, or how turn/event stats get
 recorded. Architecture detail lives in
 [`docs/turn-loop/`](../docs/turn-loop/README.md); this README is just the
 map of the module tree.
 
 ## Shape
 
+- **`main.rs`** — the serve loop and the `Surface` trait; broker calls
+  (inbox poll, ack, send) go through `hive-sock-client` with
+  `hive-core-agent-sock` wire types.
 - **`turn.rs`** — the turn-loop policy layer: renders the system
-  prompt + MCP config, invokes `hive-claude`, classifies the outcome,
-  and feeds the event/turn-stats sinks.
-- **`client.rs`** — broker client (inbox poll, ack, send) speaking the
-  `hive-sh4re` wire protocol.
+  prompt + MCP config, runs the turn through `hive-runtime`, classifies
+  the outcome, and feeds the event/turn-stats sinks.
 - **`login.rs` / `login_session.rs`** — first-run and session-resume
   auth flow for the `claude` CLI.
 - **`mcp_config.rs`** — renders the per-turn `--mcp-config` /
@@ -37,8 +39,6 @@ map of the module tree.
 - **`events.rs` / `turn_stats.rs` / `stats.rs`** — append-only event
   sink and per-turn telemetry recording (context usage, cost, tool
   favorites) under `harness/`.
-- **`forge_notify.rs`** — subscribes to forge notifications and wakes
-  the harness on new activity.
 - **`prompt.rs`** — system-prompt renderer (persona + tool docs +
   environment facts).
 - **`web_ui/`** — the per-agent dashboard (terminal pane, status,
@@ -46,6 +46,8 @@ map of the module tree.
 - **`paths.rs`** — canonical path resolution for state/harness dirs and
   the harness-local sqlite files.
 
-Sibling: **`hive-agent-mcp`** (the MCP server this loop points claude
-at every turn). Both are described together in
-[`docs/turn-loop/::Harness binary shape`](../docs/turn-loop/README.md).
+Siblings: **`hive-agent-mcp`** (the MCP server this loop points the
+agent at every turn) and **`hive-runtime`** (the library a turn runs
+through).
+[`docs/turn-loop/::Harness binary shape`](../docs/turn-loop/README.md#harness-binary-shape)
+covers all three together.