fix(notifications): deliver Telegram frames when the paired chat is not a forum

[yazzang-homelab]

What

Fix Telegram notification frames being dropped in a paired private chat whose bot has no Threaded Mode.

• isThreadedModeCapabilityRefusal now recognizes Telegram's real reply for that chat: Bad Request: the chat is not a forum.
• The suppressed/rejected verdict for createForumTopic moved from caller-local flags into typed errors (TopicCreationSuppressed, TopicCreationRejected), so every awaiter of the shared in-flight creation classifies the same rejection identically.
• A confirmed capability refusal is latched, so later frames stop re-issuing an already rejected createForumTopic once per message.

Why

TopicRegistry.getOrCreateTopic de-duplicates concurrent creations behind one in-flight promise. Only the caller that actually ran the create callback set creationSuppressed/creationRejected; any frame that joined the shared promise saw both flags false, fell through to the fail-closed branch, and rethrew:

notifications: Telegram topic creation failed: Error: createForumTopic: invalid message_thread_id
notifications daemon: handleSessionMessage failed

That frame is then dropped instead of being flat-delivered to the private chat — observed 10 times in one day on a live install (gjc 0.12.12), and the reason identity headers published after /resume (the renamed session) and pending asks never arrive.

Verified against the live Bot API for a paired private chat:

{"ok": false, "error_code": 400, "description": "Bad Request: the chat is not a forum"}

That description matched none of the refusal patterns, so the deterministic flat-delivery path was never taken and the daemon retried the rejected create for every single frame.

Testing

• New regression test private chat without Threaded Mode: concurrent frames all deliver flat in packages/coding-agent/test/notifications-telegram-daemon.test.ts: with a slow non-forum rejection, a concurrent identity_header + action_needed pair must both deliver flat, a following context_update must deliver, and only one createForumTopic attempt may be made. It fails on dev with the exact production error and passes with this change.
• bun test packages/coding-agent/test/notifications-telegram-daemon.test.ts — 553 pass, 0 fail.
• bun test scripts/telegram-daemon-generation-guard.test.ts — 48 pass; scripts/telegram-daemon-generation-guard.ts --validate-current-tree and the base/head run (v43 no protected changes) are clean.
• bun --cwd=packages/coding-agent run check — clean.

GJC verdict

gajae.pr-review-verdict.v1 needs-human sha256:0afa50eaef4d1db8ba9bab0dfa31de4abe1756e3 reviewer:human evidence:local bun test packages/coding-agent/test/notifications-telegram-daemon.test.ts

---

• Target branch is dev
• bun check passes
• Tested locally
• CHANGELOG updated (if user-facing)
• Verdict above matches the exact PR head, not an earlier commit

[yazzang-homelab]

Rebased onto current dev (11e48d5bc, #3901) — the previous head was CONFLICTING/DIRTY on the CHANGELOG ## [Unreleased] section. New head e926f2ed5; rebase was CHANGELOG-only, no code merges, and the diff is otherwise unchanged.

Re-verified on the new base: bun test packages/coding-agent/test/notifications-telegram-daemon.test.ts → 553 pass, 0 fail; bun scripts/telegram-daemon-generation-guard.ts → v43 no protected changes (no generation bump owed).