fix(api): always propagate invocationId in callback broadcasts (#454)

[mindfn]

What

• callbacks.ts: unconditionally propagate invocationId in text broadcast, rich_block system_info broadcast (post-message), and create-rich-block broadcast
• callback-document-routes.ts: add invocationId to generate-document file block broadcast
• callback-routes.test.js: 4 regression tests covering all callback broadcast paths

Why

Callback-origin websocket payloads were missing invocationId, forcing the frontend into heuristic content-matching to deduplicate late-arriving callback bubbles. Since every callback route already has invocationId in scope (required for auth), propagating it is zero-cost and gives the frontend an exact-match key.

Closes #454

Original Requirements

• 原始需求摘录：

  怎么前端还有重复消息显示的问题的；fix(#266): remove eager reconnect catch-up that caused store/ref desync #378 fix(hub): duplicate message rendering in console #266 这两个pr不都反复改了的

• 铲屎官核心痛点：Hub UI 重复显示消息气泡（callback broadcast 缺 invocationId 导致前端无法精确匹配）
• 请 Reviewer 对照上面的摘录判断：交付物是否解决了铲屎官的问题？

Plan / ADR

• Issue: fix(api,ws): always propagate callback invocationId to avoid late-callback duplicate bubbles #454
• BACKLOG: fix(api,ws): always propagate callback invocationId to avoid late-callback duplicate bubbles #454

Tradeoff

放弃了 PR #410 的客户端 heuristic 方案（time+content fence），选择协议层修复。原因：铲屎官明确要求根治而非缓解，且 invocationId 已在 callback auth scope 内，零新增字段。

Test Evidence

node --test packages/api/test/callback-routes.test.js # 80 passed, 0 failed
pnpm check # green
pnpm lint # green (only pre-existing web warnings)
pnpm -r --if-present run build # success

Open Questions

• 全量 test:public 有 pre-existing exit code 2 failure（main 上同样存在），与本 PR 无关

---

本地 Review: [x] gpt52 已 review 并放行（两轮，P2 已修复）
云端 Review: [ ] PR 创建后在 comment 中触发（见下方模板）

[mindfn]

@codex review

Please review latest commit 1d61a23 for P1/P2 only.

规则：任何 P1/P2 必须给"可执行复现"：

• 优先：新增/更新一个 failing test（最小复现）
• 否则：给确定性复现步骤（命令 + 输入 + 预期/实际）
  没有证据的一律降级为 P3 建议，不算缺陷。

审查标准（详见 AGENTS.md "Review guidelines" section）：

• P0 数据丢失/安全漏洞 | P1 逻辑错误/测试缺失/架构违规
• P2 性能/重复/命名 | P3 风格偏好
• 禁止 any、文件 200 行警告/350 硬上限、新功能必须有测试

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Breezy!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[zts212653]

Hi @mindfn — summarizing the maintainer view from both reviews:

• This is the right fix layer. Compared with fix(web): late callback dedup across invocation boundaries #410, this removes heuristic surface instead of adding more client-side coordination state.
• The scope is exactly what we wanted: small diff, protocol-level invariant, and no new frontend reconciliation machinery.
• The coverage looks complete from our side: post-message text broadcast, post-message rich-block broadcast, create-rich-block, and generate-document now all propagate invocationId.
• The regression tests match the contract we asked for, and CI is green.

We don't have additional P1/P2 concerns from the maintainer side. From our side, this is the version worth merging.

Thanks for pivoting quickly from the heuristic mitigation to the protocol fix — that's exactly the kind of course correction we hope to see in community contributions.

— 砚砚 / GPT-5.4