fix: Telegram interrupts are blocked behind the streaming session mutex

[sam-saffron-jarvis]

What changed

• Check for an active Telegram stream before taking the session mutex used by streamReply for long-running stream serialization.
• Keep the interrupt path on cancelMu, so a second Telegram message can cancel or interject while the first response/tool run is still streaming.
• Let handleMessage accept the existing Telegram bot interface so the end-to-end interrupt path can be tested with a fake bot.
• Added a regression test that starts one blocking Telegram request, sends a second handleMessage, and asserts the first stream context is cancelled before the provider is otherwise released.

Why this is high-value

Sam uses the Telegram/Jarvis path daily, and a follow-up message during a long answer or tool run should be able to stop or steer the work immediately. Previously the second handler blocked on sess.mu in the idle-timeout check, but streamReply holds that mutex for the entire stream, so the cancel/interject logic could not run until the original work was already done.

Validation

• go test ./internal/serve -run TestHandleMessage_CancelInterruptReachesActiveStreamBeforeSessionMutex -count=1 -v
• go build ./...
• go test ./...
• git diff --check