Bridge file is deprecated (`_deprecated/`). CCGram replaced it (MC-2617). Ticket targets dead code. Find the live poller — ccgram.

Ticket targets dead code. Before writing busy-lock into a file that never runs, find the LIVE injection path — where inbound Telegram messages reach a ticket's tmux pane.

CCGram source lives in workspace (`ccgram/src/ccgram/`) — the live poller+router. Check whether it already serializes sends per-target.

CCGram broker already coalesces per-target messages into ONE merged `send_keys` per serial 2s cycle — the burst-corruption risk is largely designed out. But check `tmux_manager.send_keys` for concurrent-send protection and existing `/stop` surface.

`tmux_manager.py` already has per-window `asyncio.Lock` serialization (`_vim_locks`, "Serialized per-window to prevent interleaved probes"). The requested per-target lock may already exist live. Verify the public `send_keys` path goes through it.

Clear picture now. The ticket's premise is stale. Evidence: 1. **Target file is dead code.** `scripts/mc_telegram_bridge.py` exists only in `_deprecated/` and an old build dir. `mc-telegram-bridge.service` = **disabled + inactive**. No live `.py` imports it. CCGram replaced it (MC-2617, 2026-04-29). 2. **The requested per-target busy-lock ALREADY EXISTS in the live replacement.** CCGram's `tmux_manager.send_keys` (default `literal+enter` path — the one ticket sessions use) routes through `_send_literal_then_enter`, which acquires a **per-window `asyncio.Lock`** (`_vim_locks.setdefault(window_id, asyncio.Lock())`) — "Serialized per-window to prevent interleaved probes." That IS per-target, not global. The broker additionally **coalesces** all pending messages to a target into ONE merged `send_keys` per serial 2s cycle. Burst-corruption risk = designed out. 3. **`/stop_all`** has no live equivalent — but it would target ccgram (the live system), and "arch doc roadmap item 8" belongs to the *deprecated* bridge's doc. Its spec is ambiguous (kill all windows? pause all delivery? interrupt all agents?). Writing a busy-lock into a file that never runs = misleading dead code. Let me write the findings artifact and commit it.

Pushed to `origin slot1/mc-MC-4456` (slot's current branch). Commit durable. Now report REVIEW via mc-coord.

REVIEW: MC-4453 obsolete as written. Target `scripts/mc_telegram_bridge.py` is deprecated (only in `_deprecated/`), service disabled+inactive — CCGram replaced it (MC-2617). The requested per-target busy-lock + per-target queue **already exist live** in ccgram: `tmux_manager.send_keys` → `_send_literal_then_enter` takes a per-window `asyncio.Lock` (`_vim_locks`, "serialized per-window to prevent interleaved probes"), and the broker coalesces per-target messages into one merged serial send. Items 1 & 2 done by design. Item 3 `/stop_all` has no live ccgram equivalent; its "roadmap item 8" belongs to the dead bridge's doc and spec is undefined. Wrote no dead code. Evidence committed+pushed: `docs/findings/MC-4453-telegram-busy-lock-obsolete.md`. Decision needed: build `/stop_all` on ccgram as a new scoped ticket, or drop it? {"mc_signal":"REVIEW","ticket":"MC-4453","nonce":"MC_TICKET_TURN:4457:1780141899294:0b5a9da6","payload":"MC-4453 obsolete: per-target busy-lock already exists in live ccgram (per-window asyncio.Lock + broker coalescing); target file deprecated+dead. /stop_all needs a new scoped ccgram ticket if wanted."}