#3517: fix: trigger agent response for webchat sessions after restart

Webchat sessions don't have channel/to in their delivery context, so the restart sentinel was falling back to enqueueSystemEvent() which queues the message but doesn't trigger an agent turn. This fix passes addChatRun and broadcast through to the sentinel, allowing it to register the run and call agentCommand() so responses stream to webchat clients. 🤖 AI-assisted (Claude) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR threads gateway webchat runtime hooks (`addChatRun`, `broadcast`) into the restart sentinel wake path so that after a gateway restart, a pending “restart sentinel” message can trigger an agent turn even when the session lacks a channel/to delivery context (notably webchat/WebSocket sessions). The main behavior change is in `scheduleRestartSentinelWake`, which now enqueues the restart message for context and additionally attempts to start an agent run (with `deliver: false`) when outbound delivery isn’t possible. These changes fit into the gateway lifecycle by passing runtime functions from `startGatewayServer` → `startGatewaySidecars` → `scheduleRestartSentinelWake`, aligning the sentinel wake with the same run-tracking/streaming machinery used by live webchat requests. <h3>Confidence Score: 3/5</h3> - Moderately safe to merge, but the webchat streaming path may still not be reliably triggered. - The change is small and localized, but the new `broadcast` plumbing is unused in the sentinel itself, and the sentinel-run initiation relies on assumptions about how `addChatRun` + `agentCommand(deliver:false)` produces a streamed response. Lack of error visibility (swallowed catch) also makes regressions harder to diagnose. - src/gateway/server-restart-sentinel.ts (webchat/no-channel branch) <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->