fix: wake coordinator sessions reliably - #240

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@internal/daemon/coordinator_runtime_test.go`:
- Around line 83-97: The test currently verifies prompt count, id, metadata and
message but misses asserting the InterruptIfAgentWaiting flag; update the
synthetic prompt assertions (where you call sessions.promptCount(),
sessions.promptCall(0) and inspect prompt.opts) to add an explicit check that
prompt.opts.InterruptIfAgentWaiting == true (or use a boolean assertion) so the
InterruptIfAgentWaiting bit cannot be dropped; apply the same addition to the
other similar prompt assertion sites that inspect prompt.opts (the other
promptCall checks in this file).

In `@internal/daemon/coordinator_runtime.go`:
- Around line 388-409: The drain goroutine started by coordinatorRuntime calling
drainCoordinatorPromptEvents can leak because it blocks on range events forever;
change drainCoordinatorPromptEvents to accept a context (e.g., ctx
context.Context) and inside the loop use a select to listen for ctx.Done() in
addition to receiving from the events channel so the goroutine exits when the
runtime shuts down, and update the caller in coordinatorRuntime (where
PromptSynthetic is used) to pass the runtime shutdown context (or a managed
worker context) so each wake's drain is bounded to the runtime lifecycle;
alternatively register the goroutine with the runtime's worker manager or a
WaitGroup so it is tracked and cancelled on shutdown.

In `@internal/daemon/heartbeat_wake_runtime_test.go`:
- Around line 318-389: The test currently only asserts
dispatchHeartbeatWake(...) returned false; to exercise the full fallback, after
the handled == false check call the bridge's dispatchWake(...) (the terminal
path that issues the direct PromptSynthetic fallback) with the same
harnessSyntheticWake payload, then assert sessions.syntheticPromptCount() == 1
and re-query db.ListHeartbeatWakeEvents(...) to verify the wake event reflects
the direct reentry (check Result/Reason or new event indicating the fallback was
sent); this ensures dispatchHeartbeatWake + dispatchWake end-to-end fallback
behavior is validated rather than only the helper return value.

In `@internal/session/manager_test.go`:
- Around line 2411-2493: The test
TestPromptSyntheticInterruptsAgentWaitingTurnWhenRequested must be converted to
use the required t.Run("Should ...") subtest pattern: wrap the existing test
body inside t.Run("Should interrupt agent waiting when synthetic prompt requests
it", func(t *testing.T) { ... }), move t.Parallel() into the subtest, and ensure
all uses of t (Cleanup, Fatalf, etc.) remain using the subtest's t; keep the
existing references like h.driver.cancelHook, h.driver.promptHook,
manager.Prompt, manager.PromptSynthetic, collectEvents and managerPromptCalls
unchanged inside that subtest.
- Around line 2416-2418: The cleanup currently ignores the error returned by
h.manager.Stop(testutil.Context(t), session.ID); change the t.Cleanup closure to
handle that error instead of assigning to `_` — call h.manager.Stop with the
same args and if it returns a non-nil error report it via t.Fatalf or t.Errorf
(e.g., t.Fatalf("failed to stop session %s: %v", session.ID, err)) so the test
doesn't silently swallow Stop errors; keep the call inside the existing
t.Cleanup and preserve use of testutil.Context(t), h.manager.Stop, and
session.ID.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@internal/session/manager_test.go`:
- Around line 2498-2577: The test "Should bound cancel when interrupting agent
waiting for synthetic prompt" never asserts that Cancel was invoked; after
calling h.manager.PromptSynthetic and collecting events from userEventsCh and
syntheticEventsCh, add a concrete assertion that the fake driver's cancel path
ran (e.g., assert h.driver.cancelCalls == 1 or >0). Locate the fake driver on
the test harness (h.driver) and the test block around the Prompt/PromptSynthetic
calls to insert a small retry/wait loop (with timeout) that checks
h.driver.cancelCalls to avoid flakiness, then fail the test if the counter is
not incremented.

---

Nitpick comments:
In `@internal/daemon/coordinator_runtime.go`:
- Around line 316-356: The code holds r.mu across the potentially long call to
createCoordinatorSession; release the lock before invoking
createCoordinatorSession and then re-acquire it to reconcile shared state and
update wakeInFlight so we only hold the mutex for the critical section.
Concretely: call r.activeCoordinator(...) while holding r.mu and if nil, unlock
and call r.createCoordinatorSession(ctx, decision, cfg, reason) outside the
lock; after that, re-lock r.mu, re-check r.activeCoordinator(ctx,
decision.WorkspaceID) to handle a race (if an existing coordinator appeared, use
beginCoordinatorWakeLocked(existing, decision), dispatchDecision/dispatchFailed
as before and drop the created session if needed), otherwise update wakeInFlight
with the newly created info and proceed to call beginCoordinatorWakeLocked(info,
decision), unlock, then run promptCoordinator/finishCoordinatorWake and dispatch
as the original flow intended. Ensure error paths still release the lock and
dispatchFailed consistently.