Chat intake: unconditional tracing from message-persist to turn dispatch (CL-6644)

[TheGreatAxios]

Context

CL-6644: a message POST is accepted but the agent turn dies silently — no error, no message-fanout log, no reportError, nothing — somewhere between the POST handler persisting the message and dispatchTurnBatch running. #312/#313/#314 covered the wake-hang path (bypassed timeouts on direct wakeByAddress calls); this PR picks up the next lead from CL-6644's last comment: the message POST handler's post-persist hook and the composition-root wiring in apps/hub/src/index.ts.

What I found

Traced the full path from POST /workbenches/:id/messages through sendWorkbenchMessage → routeMessage → routeToRecipients → turnQueue.run → dispatchTurnBatch → dispatchTurn → platform.sendMail → sendFoldedMailWithReclaimRetry → sendFoldedMail → the vendored sessionService.sendUserMessage. Every step is either synchronous, bounded (the reclaim-retry backoff tops out around 7.75s, wakeByAddressBounded at DEFAULT_WAKE_TIMEOUT_MS per #314), or already inside a try/catch that logs via reportError.

Live repro against the shared stack (build daed6b24) confirmed the room's host participant ("myra") is actually present in the workbench's settings (not an empty-recipients case), and the original repro's boot log shows a sidecar deploy-pack apply immediately after the failing POST. But re-sending to the same room, once that agent was already deployed and routable, produced zero log output at any layer — no wake, no deploy, no message-fanout, no reportError — which rules out the wake/deploy-hang theory as the sole explanation, since a repeat send shouldn't need to wake anything.

I did not find a smoking gun within the timebox, and per the "no guessing" bar #313 set, I'm not shipping a speculative fix. Composition-root wiring in apps/hub/src/index.ts for turnQueue/chatOrchestrator/chatPlatform reads correctly wired (verified against the #305 tasks-deletion and #294 folded-runs-split diffs — both are import-path/doc-comment changes only, no logic touched).

What this PR does instead

The one concrete, verifiable gap this investigation surfaced: every log statement on this path fires only on failure. A turn that resolves zero recipients, or one that stalls before dispatchTurnBatch's own try/catch, is indistinguishable from total silence — exactly what happened here, twice, under two different circumstances I could not tell apart from logs alone.

• routeToRecipients now logs the resolved recipient list (or its emptiness) for every message, unconditionally.
• dispatchTurnBatch logs before starting its per-recipient dispatch.
• Hub boot now logs an explicit confirmation that turnQueue, chatOrchestrator, and chatPlatform were constructed, so a future composition-root wiring mistake shows up in the boot log rather than only in a missing reply days later.

This doesn't fix the bug — it makes the next occurrence diagnosable from logs alone, without needing a live repro session first.

Verification

• WORKBENCH_CHECK_SINCE=origin/main bun run typecheck — pass
• WORKBENCH_CHECK_SINCE=origin/main bun run lint — pass
• WORKBENCH_CHECK_SINCE=origin/main bun run test — pass (198 tests, @corbits/chat included)
• Live: posted a fresh message to the reported room on the shared :3000 stack; confirmed 201 + zero downstream log activity, matching the report exactly.

Not done

• Root cause is still open. Recommend next session add temporary instrumentation inside sendFoldedMail/sendUserMessage's vendored call chain and re-drive the live repro with the new tracing from this PR in place — it will now show whether recipients resolved and whether dispatch started, narrowing the search to whatever comes after that line logs.