fix: publish the dispatch pointer for promoted queue turns

[zxch3n]

Related issue

Maintainer-authored change requested directly in a working session; there is no
prior tracking issue. The external-contribution gate does not apply here
(shouldEnforcePullRequest is false for a MEMBER author), so no issue was
opened solely to satisfy automation.

Problem / pressure

A local session surfaced message_delivery_failed ("消息送达失败 - 请在同步恢复后重发")
five minutes after its last turn finished, but every user turn had already
executed successfully. The notice was a false alarm.

Queue promotion materializes a real user turn into history but never published
latestUserMsgId, while ordinary execution advances lastHandledUserMsgId to
every turn that runs. Once a queue drained, the two pointers were left
permanently unequal: latestUserMsgId still named the last direct send,
while lastHandledUserMsgId named the last promoted turn.

getPendingUserTurnActivationId reads that plain inequality as a still-pending
activation, so the watcher entered waitForPendingUserTurnHistorySync for a
history entry that was already present and terminal — the log line "metadata is
visible but history is missing it" is misleading, because the entry exists and is
handled. After HISTORY_SYNC_WAIT_TIMEOUT_MS it ran
markMissingUserTurnRecovery, wrote lastMissingHistoryUserMsgId, and recorded
the bogus message_delivery_failed notice against a turn that had already run.

Any session whose last executed turn came from the message queue reproduces this.
It became common after #161, whose renderer routing queues on
unfinished_assistant_turn.

Diagnosis was confirmed by decoding the workspace Flock meta snapshot: the entry
clock on latestUserMsgId was still the original producer write from the first
turn, with no later overwrite. This is a missing write, not a CRDT revert or a
sync race, and the network flapping visible in the same logs was a red herring.

Summary

promoteNextQueuedMessage now publishes latestUserMsgId for the turn it
materializes, making queue promotion a dispatch producer. That restores lockstep
between the two pointers: every turn that RUNS passes through latestUserMsgId
before lastHandledUserMsgId lands on it, so a drained queue settles instead of
looking like a permanently pending activation.

lastMissingHistoryUserMsgId is deliberately not cleared. The other
producers that clear it supersede the acknowledged entry to canceled first;
promotion does not, so clearing it here would let that stale pending copy
dispatch — the resurrection apps/cli/src/session/AGENTS.md forbids. Leaving the
marker costs nothing, since it only suppresses its own turn id.

apps/cli/src/session/AGENTS.md records the widened single-writer-role
invariant: promotion is now a producer, and it is the one producer that must not
clear the marker.

Before / after

Before	After
A promoted queue turn never touches latestUserMsgId, so a drained queue leaves it naming an older turn than lastHandledUserMsgId forever	Promotion publishes the pointer, so both pointers converge on the last turn that ran
The watcher waits out HISTORY_SYNC_WAIT_TIMEOUT_MS on an entry that is already present and terminal, then posts message_delivery_failed for a turn that succeeded	No residual activation after the queue drains, so the wait and the false notice never start

Test plan

Two regression tests added in apps/cli/tests/session-dispatch-watcher.test.ts:

1. leaves no pending activation once a promoted queue turn is handled — asserts
   the promoted turn becomes the pending activation, and that after execution
   writes lastHandledUserMsgId no activation remains. Verified to FAIL without
   the fix (expected undefined to be 'queued-1').
2. keeps a missing-history marker when promoting a queued turn — asserts the
   pointer is published, the marker survives, and findNextDispatchableUserTurn
   still selects the promoted turn rather than the stranded one.

Both assert end-state behavior through the pure predicates that drive the bug,
not mock call counts.

Commands run locally:

• pnpm vitest run tests/ src/session/ in apps/cli — 916 passed, 1 skipped
  (kimi-acp-package-smoke, skipped by its own guard).
• pnpm --filter lody typecheck — clean.
• pnpm format — run; no diff left in the changed files.

Not run: the full root pnpm check (workspace-wide lint/build across every
package) and any manual end-to-end desktop run against a live queue.

Context handoff

Instructions for reviewing agents

• Review focus: promoteNextQueuedMessage in
  apps/cli/src/session/session-dispatch-watcher.ts — specifically that the new
  upsertDocMeta write is ordered after the history append, and that it does not
  clear lastMissingHistoryUserMsgId.
• Decisions to challenge: the write is an unconditional blind write of
  latestUserMsgId; a conditional "only publish when the pointer is settled"
  variant was considered and rejected, and that trade-off deserves independent
  judgment.
• Plausible failures / evidence gaps: a concurrent direct-send pointer from
  another peer can be overwritten by this write; the fallback is that the peer's
  history entry still dispatches through the pending status path, which is
  argued rather than covered by a test.

Authoring context

• User goal / directives: diagnose why a local session reported
  message_delivery_failed, then apply the pointer-publishing fix the user chose
  from two proposed options.
• Constraints / non-goals: keep the change minimal and inside the CLI
  dispatch path; the alternative option (making the recovery predicate skip
  terminal entries) was explicitly not taken, and no renderer or policy code is
  touched.
• Risk-bearing decisions: widening latestUserMsgId's single-writer role to
  include queue promotion, and deliberately preserving the missing-history marker
  so a negatively acknowledged turn cannot be revived.
• Destructive or irreversible behavior: none. The change adds one metadata
  field write; no migration, deletion, or rollback path is involved, and the
  durable turn content is written to history before the pointer.
• Deliberately not done or tested: no test covers the concurrent
  remote-producer race described above, because reproducing it needs two live
  peers; the root pnpm check was not run.
• Unknowns / confidence: high confidence in the root cause, which was
  confirmed against the real session's persisted Flock entry clocks; residual
  uncertainty is limited to the narrow concurrent-producer window.

🤖 Generated with Claude Code