telegram channel plugin (v0.0.6) connects then gets SIGINT'd immediately with --continue --channels

The telegram channel plugin (claude-plugins-official, v0.0.6) will not stay connected. It connects (stdio, ~130ms), then within ~1s the MCP server process receives SIGINT and exits cleanly — repeatedly. This makes the channel unusable for real-time inbound messages (outbound Bot API is unaffected).

Environment: Claude Code 2.1.181, macOS, bun 1.3.11, node 26.4.0. Launched via claude --continue --channels plugin:telegram@claude-plugins-official.

Log evidence (~/Library/Caches/claude-cli-nodejs/*/mcp-logs-plugin-telegram-telegram/*.jsonl): every restart shows a session id (e.g. f8455381) Successfully connected (transport: stdio), then a different session id (consistently fd4bc484..., the original --continue session) Sending SIGINT to MCP server process → MCP server process exited cleanly.

Investigated / ruled out: Claude Code/bun/node versions unchanged; bun install on start is instant (cached); token + allowlist configured (messages did arrive earlier). One real cause fixed: an orphaned poller (PPID 1) from a hard-killed prior session held the getUpdates long-poll → 409 flap. After killing it and running a single clean session (no orphans, free token verified), the connect→SIGINT cycle STILL occurs.

Hypothesis: --continue + --channels may be the trigger — the session-resume re-initialization tears down the freshly-connected channel MCP (SIGINT), so the channel never stays up. A fresh session (--channels without --continue) may not exhibit this.

Repro: run claude --continue --channels plugin:telegram@claude-plugins-official; observe the telegram MCP connect then get SIGINT'd within ~1s (see mcp-logs).

Suggested fixes: (1) don't SIGINT the channel MCP during --continue resume re-init; (2) more robust stale-poller cleanup; (3) 409 backoff instead of dropping.