Integration test for PTB polling loop

[kortiene]

Context

Session 6 refactored src/claw/telegram/bot.py to expose pure response-composition functions (compute_status_response, process_start_payload) that are unit-tested without python-telegram-bot. The closures in run_bot are now thin adapters, but Application.builder() and app.run_polling() themselves remain # pragma: no cover.

A regression that broke the handler registration order or the PTB filter set would only surface during a live smoke against a real BotFather bot.

Source: HANDOVER.md §-4.5.

Acceptance criteria

• CI gains a lightweight integration job (gated to push events, optional on PRs) that:
  • Spawns claw access serve telegram as a background process with a test BotFather token (loaded from a GitHub Actions secret).
  • Sends /help, /status, Hello, and a malformed /start pair_xxx payload via the Bot API directly (https://api.telegram.org/bot/sendMessage to a test chat).
  • Polls getUpdates for the bot's replies and asserts each one contains the expected text.
  • Tears down the bot.
• OR (cheaper alternative): a script scripts/smoke-telegram.sh documented in CONTRIBUTING.md that runs the same flow locally; CI does not run it but the runbook is canonical.
• Update HANDOVER.md §-4.5 to mark the gap closed.

Out of scope

• Mocking PTB internals — already rejected in session 6 for the unit-test path.

References

• HANDOVER.md §-4.5 (session 6 known risks)
• tests/test_telegram_bot.py (the unit-test seam)