Sends to a BUSY cursor always report failure — blind retries then deliver the same goal 3x

[EtanHey]

Etan, watching it live on two brainlayer panes: "it keeps on fucking happening". He diagnosed the mechanism himself two days ago: "for cursor it wouldn't arrive till another enter or the full turn ends. the tool is wrong tho, its there."

Evidence (screenshots 2026-08-17 18:35-18:37)

• surface:108: the same goal-file message delivered THREE times; worker's first act was "Checking for duplicate inbox messages".
• surface:109: sender side — send_to → ok:false input_still_pending; two bare submit retries → submit_evidence_absent; meanwhile the goal text sits TWICE in cursor's follow-ups queue (one queued, one editing).

Mechanism

While cursor is busy, typed text becomes a queued FOLLOW-UP delivered at turn end. No composer-clear exists for the verifier to observe, so every send to a busy cursor reads as failed even though the text is safely queued and WILL deliver. Caller sees failure → retries → each retry queues another copy → all flush at turn end → triple delivery. False failure converts an honest queued state into message spam.

Fix

1. Teach the verifier cursor's follow-up queue: detect it and return ok:true, delivery:"queued_followup", terminal:false (mirror of the busy-Codex queued path from fix: make agent delivery receipts trustworthy #404).
2. Never blind-retry into a busy cursor — check whether the text is already queued first.
3. First customer for P5b / send_to v2: background verify that confirms the follow-up flushed at turn end, instead of judging inside a 5s window cursor structurally cannot satisfy.

Related: #427, #426, #404. Urgent while cursor carries fleet implementation (until Aug 20).