A shell that asks a question at startup eats the spool's launch line, and the spawn reports success anyway

[Wirasm]

A shell that asks a question at startup eats the spool's launch line, and the pane is left at a quote> continuation prompt with no agent running.

Found incidentally while measuring #320. Not specific to that spike, and not specific to oh-my-zsh — it is a hazard for every spool spawn.

What happens

WorkbenchSpoolSpawner.send pastes the launch line and then sends Return as a separate action — correct, and the reason is recorded: libghostty wraps every sendText in bracketed-paste markers when the shell has mode 2004 on, so a line ending in \r lands on the command line and simply sits there.

But that whole sequence assumes the shell is at a prompt, ready for a command. Measured during #320: oh-my-zsh asked

[oh-my-zsh] Would you like to update? [Y/n]

at startup. The pasted launch line was consumed as the answer to that question, and the pane ended at a quote> continuation prompt. No agent started, and the spool had already reported success.

Why it matters beyond one shell

This is the same silent shape the ladder keeps hitting: the spool's job is to work when nobody is at the pane, and the failure is indistinguishable from an agent that is merely slow. It is #179's lesson in a different costume — a question nobody will be there to answer.

Anything that talks at shell startup can do this: an update prompt, a Last login banner that pages, a keychain unlock, a version-manager notice, a read in an rc file. The spawn path already checks that the shell has no child before typing — that check proves nothing is running, not that the shell is ready.

Directions, not a decision

• Wait for a prompt rather than for an idle shell. The current precondition is "the shell has no child". A stronger one would observe that the shell has actually produced a prompt — but a prompt is a rendered artifact, and helm sees ghostty's parsed actions rather than bytes, so whether this is askable at all is the first question.
• Verify after Return the way helm-spawn does. That path already requires the target shell to gain a child within 10s and refuses with its own code if it does not (helm-spawn cannot see which pane has focus, so clicking during a spawn loses the launch line #96). The spool has the same need and does not do this — it would have caught this case loudly instead of reporting success.
• Spawn with a shell that cannot ask. A non-interactive or --no-rcs invocation removes the class entirely, at the cost of the operator's own environment, which is exactly what the spool exists to hand the agent. Probably wrong, but it should be named and rejected rather than not considered.
• Detect the continuation prompt. quote> is a specific, recognisable state; so is a shell that answered something. Narrow, and it only catches the shapes anyone thought of.

Acceptance

• A spool spawn into a shell that asks a question at startup either succeeds or reports a refusal that says what happened — it does not report success with no agent running.
• Whatever lands is measured against a shell rigged to ask, not reasoned about.
• If the honest answer is that helm cannot tell a prompt from a question, say so and make the post-Return verification the fix — the failure being loud is worth more than it being prevented.