#3186: fix(telegram): sanitize update offset + lock polling

This prevents Telegram polling from silently getting stuck when persisted state is corrupted and avoids multi-poller conflicts. Changes: - Validate persisted `lastUpdateId` (must be a safe integer within the 32-bit Bot API range). If invalid, back up the file and start from a null offset. - Add a per-bot polling lock (account + token hash) to prevent multiple concurrent `getUpdates` loops. - Wire the lock + offset sanitize into the polling monitor. Notes: - Cross-platform: no systemd dependencies. - Escape hatch: set `CLAWDBOT_ALLOW_MULTI_TELEGRAM_POLL=1` to disable the poll lock. Tests: - `pnpm vitest run src/telegram/update-offset-store.test.ts src/telegram/poll-lock.test.ts` <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR hardens Telegram long-polling by (1) validating and backing up corrupted persisted `lastUpdateId` state before starting, and (2) adding a per-bot polling lock (account + token hash) to prevent multiple concurrent `getUpdates` loops. The monitor now acquires the lock before starting polling, logs invalid offset recovery via `onInvalid`, and ensures the lock is released on exit (including webhook mode). <h3>Confidence Score: 4/5</h3> - This PR is generally safe to merge, with low-to-moderate risk around edge-case lock reclamation and test flakiness. - Core behavior changes (offset sanitization + file backup, single-poller lock acquisition/release) are straightforward and covered by targeted unit tests. Main remaining concerns are an edge case where lock owner detection can misclassify a reused PID as alive on Linux when startTime isn’t available, and the new timing-sensitive test which may be flaky under CI load. - src/telegram/poll-lock.ts, src/telegram/poll-lock.test.ts <!-- 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 -->