fix(telegram): reconnect long polling after disconnect

[Alix-007]

Summary

• restart Telegram long polling when the handler or updates stream stops unexpectedly
• keep the initial startup behavior fail-fast, but add a reconnect loop for runtime disconnects
• add a regression test covering handler restart after disconnect

Fixes #216

Test plan

• go test ./pkg/channels/telegram -run TestRunPollingLoop_RestartsAfterHandlerStops -count=1

[mymmrac]

@Alix-007 I don't think this functionality is needed as long polling will stop only if context is closed, but in that case we don't need to restart it, so why this functionality is needed?

[Alix-007]

The reconnect path here is only for runtime disconnects where the updates stream stops while the channel context is still alive. Issue #216 documents that case: the gateway stays marked connected, logs a reconnect message, and then stops receiving Telegram updates until process restart.

So this does not restart after normal shutdown/cancel; runPollingLoop exits immediately once ctx.Err() != nil. It only re-establishes polling when bh.Start() returns with a live context after the updates channel has closed unexpectedly.

I also pushed a small lint-only follow-up and re-ran:

• go test ./pkg/channels/telegram -run TestRunPollingLoop_RestartsAfterHandlerStops -count=1

[Alix-007]

Closing this for now.

After re-checking the current implementation and the upstream telego behavior, I do not have enough repository-specific evidence to keep this PR open:

• picoclaw uses github.com/mymmrac/telego v1.7.0, not go-telegram-bot-api
• telego's UpdatesViaLongPolling already retries GetUpdates errors internally by default, so ordinary polling/network hiccups do not appear to close the updates channel in the way this PR assumes
• the current regression test exercises a forced handler/channel-stop path, but it does not demonstrate a real telego failure mode seen in picoclaw itself

Given that, and given the PR is now conflicting with main, I think the right move is to close instead of continuing to maintain a fix without a solid reproducer.

If we get a telego-specific reproducer or logs showing the updates stream really exits while the channel context is still alive, I can reopen this as a narrower follow-up.