fix: Telegram interruption can hang forever while closing an uncooperative stream

[sam-saffron-jarvis]

What changed

• Cancel Telegram response contexts before beginning stream cleanup.
• Run Stream.Close asynchronously and bound cleanup across the stream consumer, direct stream close, and shared runner.
• Mark runtimes stale when cleanup misses the deadline so the next message replaces the runtime instead of reusing one still owned by detached work.
• Skip abnormal transcript reconciliation when a detached producer could still mutate callback output.
• Add table-driven regression coverage for an uncooperative Stream.Close on user interruption and a Runner.Run that ignores watchdog cancellation.

Why this is high-value

Telegram holds the per-chat session mutex for the full response. Previously, interruption and error paths could call Stream.Close or wait for runner shutdown without a deadline, leaving replyDone open and the session mutex locked forever. A handful of stalled responses could retain every Telegram handler slot and stop the bot globally. Cleanup is now bounded, the old runtime is quarantined, and a replacement session can process the next message.

Validation

• gofmt -w internal/serve/telegram.go internal/serve/telegram_test.go
• go test ./internal/serve -run 'TestStreamReply_UncooperativeCleanupIsBounded|TestStreamReply_PersistsInterruptedPartialAssistantReply|TestStreamReply_WatchdogTimeoutIsNotTreatedAsUserInterrupt' -count=1
• go test -race ./internal/serve -run TestStreamReply_UncooperativeCleanupIsBounded -count=1
• go test ./internal/serve -count=1
• go build ./...
• XDG_CONFIG_HOME=$(mktemp -d) go test ./...
• git diff --check