Point plugin authors to capabilities.tts.voice.captionedFinalText instead of
resolveChannelTtsVoiceDelivery, which is a core runtime resolver, not a
plugin implementation hook. Add a complete capabilities snippet matching the
Telegram reference implementation.

Narrow block suppression to text-only payloads on both ACP and non-ACP
dispatch paths. Blocks containing media, presentation, interactive, or
channelData are now delivered with text stripped instead of being silently
dropped.

Add captionedFinalText capability guidance to the channel plugin SDK docs.

Add regression tests for media-block delivery and text-only suppression
on both dispatch paths.

Extend captioned-final text stripping to the onToolResult delivery path
on both ACP and non-ACP dispatch paths. Tool results carrying media now
drop their text to prevent duplicating the final voice note caption.
Text-only tool results are preserved — they are progress/status, not
caption content.

Uses media-only check (via resolveSendableOutboundReplyParts) instead of
the broader block-path check to preserve text on interactive/approval
tool results that have no media.

Enhance captionedFinalText JSDoc to warn that incorrect opt-in silently
loses reply text.

Add regression tests for tool-result media text stripping and text-only
tool result preservation on both dispatch paths.

- Remove unused result binding in captioned final TTS dispatch-acp test
- Type mock.calls accesses for dispatcher and routeReply payloads
- Allow resolveStatusTtsSnapshot mock to return null per production signature
- Enable verbose progress in the text-only tool-result test so the
  result is actually delivered (text-only progress is suppressed by
  default), matching production behavior

Compute final TTS media delivery from the actual route/dispatcher outcome
instead of the pre-send payload shape. Previously deliveredMedia was true
whenever the captioned final voice payload carried a media URL, even when
routeReply returned { ok: false } or sendFinalReply returned false. Because
block text is suppressed for captioned final TTS, the accumulated-text
fallback gate was then short-circuited and the reply content was dropped on
a failed final voice send.

deliveredMedia is now gated on confirmed delivery (routed delivery for the
route path, queuedFinal for the dispatcher path), so a failed or suppressed
captioned voice send still lets the accumulated block text fallback run.

Add regression tests covering both the dispatcher and route delivery paths.

…al media

A suppressed route-reply means the hook cancelled the send and nothing
reached the user, but the suppressed branch still set deliveredFinalTtsMedia.
finalizeAcpTurnOutput gates the text fallback on that flag, so a suppressed
final-media route silently dropped the routed reply text. Leave the flag
false on suppression so the text fallback can still fire.

…tate

A hook-suppressed routed final reply (route-reply returns ok+suppressed)
is handled but never reaches the user. Both the ACP and non-ACP captioned
final-mode TTS fallback gates keyed off handled signals (deliveredFinalReply
/ queuedFinal and the raw deliver() return), so a suppressed captioned voice
send skipped the text fallback and silently dropped the reply.

Separate handled from delivered-to-user: add deliveredFinalReplyToUser to the
ACP coordinator (set only on genuine routed/direct delivery) and a deliveredFinal
result on the non-ACP sendFinalPayload. The captioned-final fallback gates now
read the delivered-to-user signal while the no-reply/abort guards keep reading
the handled flag. Adds suppressed-route regressions on both paths.

…t inline wait

The non-ACP direct dispatcher branch treats the enqueue-only return of
sendFinalReply as proof the reply reached the user. sendFinalReply only queues;
the visible send (e.g. Telegram sendVoice) settles asynchronously and can fail
later. When a captioned final TTS suppressed the accumulated block text and the
voice then failed async, the block-text fallback was gated off (it keys on
delivered-to-user state), so the user received nothing.

The reply operation must not block on dispatcher.waitForIdle() — a queued
follow-up would deadlock completion against dispatcher idle (removed upstream in

So drive the recovery off the same settle lifecycle: sendFinalPayload keeps its
optimistic queued gating and surfaces the pre-send final outcome counts for the
direct-dispatcher path. When a captioned final (or the synthesized-voice sibling
path) is admitted through the raw dispatcher, register a post-settlement task
(registerReplyDispatcherSettledTask) that re-sends the accumulated block text as
a text-only final if the voice failed/cancelled. It runs after waitForIdle inside
settleReplyDispatcher, out of the reply hot path, so completion never blocks.

Rewrite the captioned-final media-failure regression to model async failure
(sendFinalReply returns true, getFailedCounts reports the failure after
waitForIdle) and settle the dispatcher, and add a sibling test for the synthesis
fallback path.

In captioned-final TTS mode, text-only blocks are suppressed and accumulated
so the final captioned voice carries them. If the final reply turned out to be
ordinary media (an image or file rather than a synthesized voice), the delivery
accounting treated that media as delivered TTS media and the final as delivered
to the user, which closed the accumulated block-text fallback gate. The user
then received only the image and the assistant text was dropped.

maybeApplyTts returns the reply unchanged when it already has media, so no voice
is synthesized in that case. Distinguish genuinely synthesized captioned media
(no media in, media out) from ordinary final media by capturing the original
reply's media state before TTS, and only count synthesized media as delivered
TTS media at both delivery sites.

Fixing the media flag alone is not enough because the fallback gate also blocks
on delivered-to-user, which an ordinary media-only final still sets. Add a
deliveredFinalVisibleText signal and, in captioned-final mode only, gate the
fallback on delivered visible text or delivered TTS media instead of generic
delivered-to-user. Non-captioned and directive paths keep their existing
delivered-to-user semantics.

Narrow the ACP coordinator's final-media check to genuine TTS supplements as a
defensive invariant; ACP only emits text finals plus the synthesized voice
today, but this prevents a future ordinary media-only final from regressing the
same gate.

Add a regression where a captioned final is ordinary media-only after a
suppressed text block, asserting both the media and the accumulated text reach
the user, plus an ACP delivery test asserting non-supplement final media does
not satisfy the TTS-media gate.

The ACP dispatch delivery coordinator now resolves the reply delivery
account via resolveReplyDeliveryAccountId, which reads
plugin.config.defaultAccountId. The dispatch-acp test's mock plugin did
not provide a config object, so the resolver threw. Add a config stub
matching the dispatch-acp-delivery test mock.

The captioned-final text docs described block-text suppression and caption
bundling unconditionally, but caption deferral of ordinary block text only
engages when the resolved auto mode is not tagged. In tagged mode plain block
replies with visible text stay visible; only the live partial-reply preview is
held back, and a directive-only final reply attaches its resolved directive
text as the voice-note caption. Scope the wording in both the SDK channel
plugin docs and the TTS tool docs so plugin authors do not assume plain tagged
replies are hidden.

…lback

When a captioned final-mode voice note is deferred, block text is
suppressed on the assumption the voice note will carry it. The deferred
text fallback only cleared the delivered flag when the final send
failed, but a before-deliver / reply_payload_sending hook returning null
cancels the send after enqueue() already reported acceptance. That
outcome is tracked as cancelled, not failed, so the queued voice was
counted as delivered and the plain-text fallback never fired, silently
dropping the reply.

Fold cancelled block/final counts into the ACP direct-visible-text
settlement accounting alongside failed counts, so a cancelled captioned
voice final clears finalMediaDelivered and the deferred text fallback
delivers. Add readDispatcherCancelledCounts mirroring the failed reader,
and a regression test covering an asynchronously cancelled captioned
voice on Telegram.

…utcome

Non-ACP captioned-final recovery compared aggregate dispatcher final
cancelled/failed counts before vs after the whole dispatcher drained.
Because one reply can enqueue multiple finals (a captioned voice plus
sibling reasoning/commentary/status finals), a sibling final's failure
or cancellation inflated the aggregate delta and re-sent text the voice
note had already delivered as its caption, reintroducing the duplicate
churn this change eliminates.

Move the non-ACP path to per-payload outcome attribution, matching the
ACP path: add a core-internal per-payload delivery-failed observer that
is symmetric to the existing per-payload cancelled hook, and drive
registerCaptionedFinalTextRecovery off this captioned voice payload's
own cancelled/failed outcome (identified by a capture token) instead of
the aggregate counters. Recovery now re-sends the deferred text if and
only if this voice's own send was cancelled or failed.

Add a mixed-outcome regression: a captioned voice that succeeds while a
sibling final fails must not re-send the caption text.

Remove the 'notifies appended delivery-failed observers when deliver
throws' test and its appendReplyDispatcherBeforeDeliverFailed import.
That helper has no source definition or production consumer, so the
test referenced a symbol that never existed, breaking type-check and
the suite. The retained cancellation-observer coverage
(appendReplyDispatcherBeforeDeliverCancelled) still exercises the real
implementation used in dispatch-from-config.transcript.ts.

…zed ACP delivery test, safe mock destructure

- Remove retired coalesceIdleMs/maxChunkChars keys from ACP stream test
  configs (they were retired in 783a5d2 and are asserted dead in
  dead-config-keys.test.ts; the runtime ignores them), fixing TS2353.
- Replace unsafe [[x]] tuple destructures of mock.calls with the existing
  expectDefined(...) accessor to fix TS2488.
- Extract shared setup/fixtures from dispatch-acp-delivery.test.ts into
  dispatch-acp-delivery.test-utils.ts to satisfy the max-lines lint rule
  without weakening any test; keep vi.mock in the test file for hoisting.
- Reformat the touched test-utils file.