#16501: feat(telegram): add inbound subagent queue with prefork progress

## Summary This PR adds a built-in Telegram inbound subagent queue with prefork-oriented dispatch and user-visible progress updates. ## Why Before this change, Telegram inbound messages on the subagent path had no dedicated built-in queue worker and no clear lifecycle feedback. Users could not reliably tell whether a message was queued, actively processing, or no longer running. This was especially painful during development and operations: after service/container restarts, users had no clear signal to distinguish “still processing slowly” from “processing was interrupted and is no longer progressing.” By adding a built-in queue worker with explicit queued/processing progress states and prefork dispatch, we improve both perceived responsiveness and operational clarity. ## Problem solved 1. Unclear waiting state for Telegram users (queued vs processing vs stalled). 2. Extra startup latency before subagent dispatch. 3. No dedicated per-chat/global concurrency control for this Telegram inbound subagent path. 4. Weak continuity for queued turns across follow-up processing. ## What changed 1. Add TelegramInboundSubagentQueue for Telegram inbound -> subagent execution. 2. Queue messages and dispatch subagent runs in prefork mode. 3. Add global/per-chat inflight limits for fairer and safer burst handling. 4. Add Telegram queue memory persistence to improve context continuity. 5. Add progress/status feedback for queued and processing states. 6. Add prefork timing test coverage. ## Benefits 1. Faster time-to-dispatch. 2. Better Telegram UX with clear processing feedback. 3. Improved robustness under traffic bursts. 4. Better context continuity for queued conversations. 5. Better observability via queue timing logs. ## Validation - `pnpm build` passed - `pnpm vitest src/telegram/inbound-subagent-queue.prefork.test.ts src/telegram/bot-message-dispatch.test.ts` passed - `pnpm check` has unrelated existing baseline errors outside this change <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR introduces a Telegram inbound subagent queue with prefork dispatch and progress updates. The implementation adds a dedicated queue worker (`TelegramInboundSubagentQueue`) that manages inbound Telegram messages, dispatching them to subagents with improved UX through status updates and concurrency controls. **Key changes:** - New `TelegramInboundSubagentQueue` class with global/per-chat concurrency limits (3 each) - Queue memory persistence in session store for better context continuity - Prefork dispatch pattern - starts agent execution before sending reactions/status - Live progress updates showing queued → processing states with typing indicators - Test coverage for prefork timing behavior **Implementation approach:** - Messages are enqueued when gateway is reachable and valid messageId/body exist - Queue uses `pump()` pattern to dispatch tasks respecting inflight limits - Each task sends status message → loads memory → dispatches subagent → polls for completion → updates with final response - Progress updates occur every 4s (typing heartbeat) with snippet from latest assistant reply - Queue disabled in vitest (`process.env.VITEST === "true"`) to avoid affecting existing tests <h3>Confidence Score: 4/5</h3> - This PR is generally safe to merge with comprehensive test coverage and good error handling, though one edge case warrants attention. - The implementation is well-structured with proper concurrency controls, error handling, and test coverage. The queue disabled in tests via environment check prevents disruption to existing test suite. One minor concern: the `pump()` method has a potential edge case where rapid concurrent calls could theoretically lead to redundant pump cycles, though the `pumping` flag mitigates this in practice. - Pay close attention to `src/telegram/inbound-subagent-queue.ts` - review the pump() concurrency logic and ensure the inflight counter management is correct under all scenarios. _{Last reviewed commit: e34c946} <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->