fix(#1543): drive request_next_turn continue in-process, not via the broker

docs/turn-loop.md

@@ -82,7 +82,7 @@ zero-sized impl (`AgentSurface`) wrapping:
 
 - One async method per wire op: `ack_turn`, `requeue_inflight`,
   `inbox_unread`, `post_turn_counts`, `send_to_parent`,
-  `self_wake`, `recv_next`, `wake_external`.
+  `recv_next`, `wake_external`.
 
 `main()` calls `serve_main::<AgentSurface>` for all roles. The turn
 loop (`serve_loop` / `handle_turn` / `wake`) has no per-role branches.
@@ -117,9 +117,19 @@ and the manager fall through to operator).
 
 After the outcome handler, the stats sink records a row and the
 `hyperhive-continue` sentinel (dropped by the `request_next_turn`
-MCP tool) is consumed if present, firing `self_wake` so the next
-turn starts with `{ from: "self", body: "continue" }` even if the
-inbox is empty.
+MCP tool) is consumed if present. `handle_turn` reports the result
+to `serve_loop` via `TurnControl { auth_failed, continue_requested,
+pending }`. When a continue was requested, the turn did not
+auth-fail, and the inbox is empty (`pending == 0`), `serve_loop`
+drives the next turn in-process with a synthetic
+`{ from: "self", body: "continue" }` message (`synthetic_continue`)
+— it never goes through the broker, so the self-continue doesn't
+persist to sqlite or show up as a recv'able inbox message. If real
+messages are already pending the continue is dropped: those messages
+drive the next turn(s) via `recv_next`, so an explicit self-wake
+isn't needed (this is the `request_next_turn` contract — "no effect
+if a new inbox message arrives before this turn ends"). The
+`should_self_continue` predicate encodes exactly that decision.
 
 ## The claude invocation