spawn_task / dismiss_task: the documented replace order (spawn new, then dismiss old) double-dispatches when the old chip has already been started

What happened: the assistant wanted to correct a chip it had just created (one identifier in the prompt was wrong). It issued dismiss_task for the old chip and a new spawn_task in the same response. (The dismiss_task description suggests the opposite order for replacing a chip: "call spawn_task with the new suggestion first, then dismiss the old task_id".) The user had started the first chip about 15 seconds after it was created, so dismiss_task returned "already started … can't be withdrawn", but the replacement chip had already been emitted. The user started that one too, and two sessions began the same task.

Why it happens:

• Chips are started by people within seconds. By the time the assistant's next turn arrives, "pending" is usually no longer true.
• Within one response the assistant cannot read the dismiss result before the next tool call, so "dismiss, and re-create only if it worked" cannot depend on the result unless it is split across turns.
• The documented order (spawn first, then dismiss) produces a duplicate whenever the old chip has already started.

Suggestions (any of these would help):

1. Change the documented replace order: dismiss first, and create the replacement only after reading a "withdrawn" result. If the result is "already started", message the running session instead of creating a new chip.
2. Have spawn_task refuse, or warn, when this session already has a pending chip or a running session with the same title.
3. Include the started session's id in the "already started" result, so the assistant can message it (related: #93880, #84930).

Environment: Claude Code desktop on macOS, 2.1.280.