Fix Save draft when forking threads

[ymichael]

Human comments

Before / After

Both captures use the supported product journey Fork into new thread → enter the shown prompt → Save draft… → Save draft in the real source Chromium app. The QA threads were validated as M4 / Codex / gpt-5.6-sol / high / default / full. Assets are pinned to the separate evidence-only root commit 722baf85893192feef86a5fccb94e3d8de74ad03; PR head contains no screenshot commit.

Before — broken baseline

After — repaired

Provenance: baseline endpoint 054de3ae9c4d9551c845ada6549da5490af78988, captured before source edits. Shown prompt: “Fork draft before fix 054de3a — must remain queued and must not run.” Observed: the fork is active (Working…), the prompt was accepted, provider output and command-tool work began, and the queue was empty.

Provenance: repaired commit 065b5bf3ed3799efe2c2531a031878a6e78cdd74, same source-app journey. Shown queued draft: “Fork draft after fix 054de3a — must remain queued and must not run.” Observed: the fork is inactive, with exactly one queued row held by Drafts · Draft. CLI/server evidence confirmed the inherited timeline remained at seq 5 with no matching requested or accepted provider turn and no new tool work.

What was wrong

The fork flow introduced in #3575 rebuilt the new-thread submission through buildForkThreadRequest but omitted the composer's pluginSubmission. That stripped the Drafts plugin marker before the initial dispatch hook could see it, so Save draft displayed success while core treated the fork prompt as an ordinary message and immediately started a provider turn. Root and follow-up drafts were unaffected because those paths forwarded the submission unchanged.

What changed

buildForkThreadRequest now requires callers to account for pluginSubmission and preserves it when present. RootComposeView forwards the composer's value into the shared builder. The opaque plugin data still exists only during dispatch-hook processing and is not persisted in the accepted core message. No server, daemon protocol, CLI, SDK, or documentation contract changed.

Added focused coverage for plugin submission on fork dispatch, an ordinary-fork control with no plugin submission, and controls proving root/new-thread and follow-up composers still forward plugin submissions.

How you verified

• Red/green fork assembler regression: 6/6 passed after the fix.
• Root/new-thread and follow-up composer suites: 81/81 passed.
• Drafts plugin tests: 6/6, plus typecheck.
• Server dispatch-hook suite: 15/15 passed.
• Turbo typechecks for @bb/client-core and @bb/app passed.
• Real source Chromium journey: Fork into new thread → Save draft now creates an inactive fork with one exact queued draft and no accepted turn/tool work; Send now dispatches exactly once.
• Source CLI smoke on the production worktree build: ordinary fork produced one request/acceptance, no queue or tools, and passed the M4/Codex/gpt-5.6-sol/high/default/full validator.

AGENT GENERATED