[Bug]: native-runtime 验收把命令写进了还没启动完的 shell — 5 秒轮询预算被 shell 启动吃掉 #33

What breaks

The native-terminal acceptance fails in the test body on the Windows runner:

packages/webui/test/browser/native-runtime.spec.mjs
expect.poll(async () => (await rpc(page, "listTerminals"))[0].output).toContain("WEBUI_NATIVE_ALIVE")
-> Timeout 5000ms exceeded while waiting on the predicate

The teardown's second complaint ("exited" received 1 instead of 6) is a consequence:
the body failed first, so only one terminal was ever created.

Why it happens

The command is written into a shell that has not finished starting up.

The failing run's Playwright trace (artifact webui-browser-windows-latest-1, trace.zip,
which carries the raw return of every listTerminals call) gives the timeline,
with T0 = the moment writeTerminal wrote the command:

The shell's own start-up took about four of the five seconds the wait was given.
At the moment the wait gave up, the buffer held the echoed command and no output
line -- the command had not been executed yet, so this is not "the echo was late".

The command itself is written to make a false positive impossible
(Write-Output ('WEBUI_NATIVE_' + 'ALIVE')), so the literal string can only appear
in a real output line. That part of the test is sound.

How often

• The fork's 152 CI runs contain 10 failed native-runtime jobs. Their forms:
  1 x this one (the body's five-second wait), 1 x the teardown stall (see [Bug]: the native acceptance teardown still times out on Windows — the host stalls inside the service close #30),
  7 x "the native host never started", 1 x "the beforeAll hook timed out".
• This form was seen exactly once: run 42966373896, Windows attempt 1,
  job 130344433067. The same job's second attempt passed, and the branch's later run
  (42971475734) passed on Windows on the first attempt.
• On the base commit there was only one native-runtime opportunity and it passed.
  The honest wording is therefore "not observed on base", not "impossible on base".

What this is not

• Not the pixel/visual baselines (no screenshot mismatch is involved).
• Not the teardown stall -- that is [Bug]: the native acceptance teardown still times out on Windows — the host stalls inside the service close #30, a different fault in a different place.
• Not introduced by the change in fix(webui): the native acceptance names the step it stopped at, and keeps our preload out of node-pty's helper #31: fix(webui): the native acceptance names the step it stopped at, and keeps our preload out of node-pty's helper #31 touches the teardown hook and the
  process flags, never the body, and the failure is in the body.

Direction of a fix

Wait until the shell is actually up before writing into it, so the five seconds are
spent on the echo rather than on the shell's start-up. The wait for readiness needs its
own bounded budget and has to fail with a readable message saying how far the terminal
got. Nothing is to be relaxed: the five-second budget for the echo stays five seconds,
no retry is added, no case is skipped, and the expected string does not change.

The same test runs on macOS and Linux, where the shell starts quickly; the readiness
gate must not disturb them.