Best possible solution:

Land the PR after required exact-head checks pass, preserving the fresh-final runtime path plus the regression test, Telegram docs, and changelog coverage.

Do we have a high-confidence way to reproduce the issue?

Yes at source level. Current main can send a visible block/error bubble after a short-lived Telegram preview and then edit that older preview into the final answer; the PR adds regression coverage for that sequence.

Is this the best way to solve the issue?

Yes. Tracking the last successful visible non-preview send in the dispatcher and comparing it with the active preview timestamp is a narrow fix that avoids new configuration or broader delivery policy changes.

What I checked:

• Current main uses only the long-lived preview threshold: On current main, shouldUseFreshFinalForLane and shouldUseFreshFinalForPreview only force fresh finals when the preview is older than the one-minute threshold; they do not account for a later visible tool/block/error bubble. (extensions/telegram/src/lane-delivery-text-deliverer.ts:207, e2c8db2cad40)
• Current test documents the problematic old order: The existing dispatcher test sends an error block after a preview and then expects the final answer to edit the preview in place, matching the reported out-of-order Telegram display path. (extensions/telegram/src/bot-message-dispatch.test.ts:3182, e2c8db2cad40)
• PR diff adds dispatcher state for visible non-preview sends: The PR records lastVisibleNonPreviewDeliveryAtMs after successful sendPayload delivery and passes a getter into the lane text deliverer. (extensions/telegram/src/bot-message-dispatch.ts:729, b5a61cd25a68)
• PR diff applies the fresh-final decision: The lane text deliverer treats a visible non-preview delivery newer than the preview's visibleSinceMs as a fresh-final condition, alongside the existing long-lived preview rule. (extensions/telegram/src/lane-delivery-text-deliverer.ts:208, b5a61cd25a68)
• Prior docs gap is addressed: The latest PR diff updates the Telegram docs to describe fresh final delivery after visible non-preview output, addressing the earlier P3 docs finding. Public docs: docs/channels/telegram.md. (docs/channels/telegram.md:303, b5a61cd25a68)
• Git history routes the area to recent Telegram maintainers: git log and git blame show recent Telegram delivery and docs work by steipete, thats2easyyy, and GodsBoy around the touched files. (extensions/telegram/src/lane-delivery-text-deliverer.ts:199, 63ff9244c711)

Likely related people:

• steipete: Blame for the current lane text deliverer and recent Telegram docs history point to Peter Steinberger as the main maintainer adjacent to preview finalization and delivery behavior. (role: recent Telegram channel maintainer; confidence: high; commits: 63ff9244c711, e2c8db2cad40; files: extensions/telegram/src/lane-delivery-text-deliverer.ts, docs/channels/telegram.md)
• thats2easyyy: Commit history for bot-message-dispatch.ts shows recent adjacent Telegram dispatch maintenance in the same delivery pipeline. (role: recent adjacent maintainer; confidence: medium; commits: 796c1e67c3d9; files: extensions/telegram/src/bot-message-dispatch.ts)
• GodsBoy: Recent history for docs/channels/telegram.md includes Telegram streaming documentation work near the PR's docs surface. (role: recent Telegram docs maintainer; confidence: medium; commits: b336efdd9cfd; files: docs/channels/telegram.md)

Remaining risk / open question:

• Exact-head CI results were not available in the supplied context, so normal required checks should still gate merge.

Codex review notes: model gpt-5.5, reasoning high; reviewed against e2c8db2cad40.