#6463: fix(telegram): improve timeout handling and prevent channel exits

## Summary - Reduces maxRetryTime from 5 minutes to 2 minutes for faster recovery from persistent errors - Adds retryInterval: "exponential" to use exponential backoff between retry attempts - Improves error classification for timeout vs conflict vs generic network errors - Updates test expectations to match new timeout configuration ## Test plan - [x] Unit tests pass (`pnpm test src/telegram/monitor.test.ts`) - [x] Linting passes (`pnpm lint`) - [x] Formatting passes (`pnpm format`) - [ ] Manual testing with Telegram bot to verify timeout recovery behavior <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> Changes adjust grammY runner retry/timing behavior for Telegram polling: `maxRetryTime` is reduced (5m → 2m) and `retryInterval: "exponential"` is set, while `monitorTelegramProvider` now classifies timeout-like `AbortError`s as retryable and adds a hard cap on poll restarts. Tests were updated to match the new runner options. Main behavioral shift is in the polling loop error/abort handling and restart policy in `src/telegram/monitor.ts`, with a corresponding expectation change in `src/telegram/monitor.test.ts`. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge, with a couple of behavioral edge cases to confirm around abort propagation and retry attempt counting. - Core changes are localized and test updates reflect new config, but `monitorTelegramProvider` now swallows abort rejections (behavior change) and the restart attempt cap appears off-by-one relative to the intended limit/logging. - src/telegram/monitor.ts <!-- greptile_other_comments_section --> **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->