Telegram: route a reply to the session that sent the replied-to message

[serxa]

What

Replying (a Telegram reply) to a message routes your reply to the session tied to that message, instead of the chat's active session — and makes that session active. This makes it easy to:

• answer messages from cron / background sessions (previously hard to send into),
• reply to your own earlier message to jump a reply back into whatever session that message went to, and
• talk to several sessions by replying, without an explicit /session switch.

Plain (non-reply) messages are unchanged: they still go to the active session.

How

• Recording (both directions): the Telegram channel keeps a bounded LRU message_id -> (chat_id, session_id), populated for
  • every message the bot sends — interactive turn responses (TelegramChannel.send) and notification / ask_user delivery (NotificationService._deliver_telegram, the cron case), and
  • every inbound message, against the session it lands in (_delivery_session — the resolved reply target, else the active session). This is what lets a reply to your own message route to that message's session.
• Inbound: _resolve_reply() classifies a message three ways: not a reply → active session (default, unchanged); reply to a mapped, live session → route there + make active; reply that can't be resolved → reject (below).

Safety: an unresolvable reply is rejected, never mis-routed

An explicit reply we can't tie to a live session — the target message isn't in the map (sent before the daemon started, since the map is in-memory; or evicted from the LRU), its session is archived/gone, or the chat id doesn't match — is not delivered to the active session (that would be a silent mis-route). Instead the bot sends a static, no-LLM nudge ("couldn't find the session… use /sessions and resend") and drops the message without starting a turn. Resending is cheap; a mis-route is not.

Behavior choice

Routing is sticky — a reply also makes the target session active (like /session <id>), so a following plain message continues there.

Testing

• tests/test_telegram_reply_routing.py (17 tests): record/lookup, chat-mismatch isolation, empty-session no-op, LRU eviction + recency, three-way _resolve_reply (active / route / reject across live / missing / archived / unmapped / chat-mismatch), _delivery_session (routed vs active fallback), reply-to-own-recorded-message routing, and send() recording.
• Full suite: 3375 passed; the only 2 failures (test_config_env, test_lockdown) reproduce on clean main in this environment and are unrelated to this change.