fix(telegram): make the StopFailure send leg observable and never silently lost (DIVE-4401)

[5dive-bot]

DIVE-4401 iteration 2 — the send/route leg

Iteration 1 (5dive-ai/5dive#921) closed deliverable 4 and the pane-side half of
deliverable 1, and the verifier banked it. It also found — and the verifier
confirmed at source — that the Team wall was not a classification miss. This
PR finishes the leg that finding named, in the repo the row scopes.

What was actually wrong

The hook's send DECISION is provable for the measured 2026-09-13 04:20Z episode
without any log: resume-after-reset's spawn is gated on the same
shouldSend as the DM (stopfailure-notify.ts, DIVE-1107), and both seats'
helper logs exist and parked to reset_epoch=1789290000. So SEND, on both.

Everything after the decision was unrecorded:

• sendMessage returned void and never looked at the response. fetch
  resolves on a 4xx, so a rejection (bad token, bot removed from the group, a
  message_thread_id for a topic that no longer exists) read exactly like a
  delivered message.
• A network throw was swallowed by a bare catch {}.
• Nothing logged where the notice was routed. The two seats took two
  different rungs and left no trace of it: main had a Telegram DM 11 minutes
  before the wall → getCallerChat → the operator's DM; olivia's turn was
  autonomous → getGroupTopics → the agent's own forum topic, which is the
  documented behaviour and is not the DM the operator was watching.

So "the bot never sent it", "the bot sent it somewhere you weren't reading" and
"Telegram rejected it" — three symptoms with three different fixes — were one
indistinguishable silence, and the episode could not be attributed hours later.

Changes

• lib/telegram.ts — sendMessage returns whether Telegram accepted the
  message and reports on stderr: REJECTED <chat[:topic]> — http <status> — <description>, FAILED … — <network error>, and a missing TELEGRAM_BOT_TOKEN.
  TELEGRAM_API_BASE exists so the leg can be pointed at a stub and asserted;
  it had no driven coverage precisely because it could not be pointed anywhere.
• stopfailure-notify.ts — logs route=caller|group-topics|all-allowed
  with its targets, then each send's outcome. Routing is unchanged (row
  deliverables 2/5): a Team wall lands exactly where a Pro/Max wall lands.
• Fallback on TOTAL failure only — if every routed send fails, retry on the
  paired chats not yet tried, so a dead topic degrades to a DM instead of to
  silence. A successful routed send never fans out (asserted).
• resume-after-reset.ts — logs the chats it was handed. Its log is the one
  artifact of a wall episode that survives the systemd respawn, and it printed
  everything except the answer.

Evidence

test/stopfailure-send-leg.test.ts — 8 arms, executing the real hook in a
subprocess against an out-of-process Bot API stub (out-of-process is
load-bearing: the hook is driven with spawnSync, which blocks the test's event
loop, so an in-process server could never answer and every arm would time out
and assert nothing).

Both fixtures are the measured shapes; the wall copy is the measured Team copy.

arm	asserts
caller turn	one transmission, to the DM, no topic; route=caller; send …: ok
Team vs Pro/Max	identical chat + topic for both wall texts
autonomous turn	the group topic, not the DM (the verifier's empty-getCallerChat control)
5 repeats	1 SEND + 4 suppress and exactly one transmission
rejection	REJECTED -100…:1417 — http 400 — message thread not found
fallback	topic rejected → the DM receives it, logged
no fan-out	a delivered notice contacts exactly one chat
nowhere to fall back	http 403 — bot was blocked by the user + "no other paired chat"

Mutation, anchored per arm: ignore res.ok (the pre-fix behaviour) → 3 red ·
drop the fallback → 2 red · drop the route trace → 3 red · drop the per-send
outcome → 2 red. No mutant reds another's exclusive arms.

Regression: full repo suite bun test → 1194 pass / 0 fail (1186 before
these 8 arms).

Not claimed

Whether Telegram accepted the 04:20Z sends is unknowable now — the code that
would have recorded it is the code this PR fixes. The one-line
resume-after-reset chats log has no arm (driving it needs a live tmux pane).

🤖 Generated with Claude Code