test(the-framework): bind a topic run only once it is up (#1165)

[suleimansh]

Closes #1165.

What it actually was

Not a poll budget, and not the settle() teardown the issue's working theory pointed at. I reproduced the exact CI signature locally and it is a test artifact, not a production bug.

tearDownTopicScratch only removes a scratch whose meta reads done; the test's meta reads running, so that path is a no-op here and could never have produced scratch removed: true. The only other remover is the success path of rehomeTopicRun. So on the failing runs the re-home worked: worktree allocated, history moved, continued run spawned, scratch removed. The missing start was the topic run's own.

Why it went missing: the test seeds the bind the instant onStart returns, which fires a re-home that calls terminate(child.pid) on a child that may still be booting. Under load the SIGTERM lands before the stub reaches its first write, the process dies on the default disposition, and its argv line never appears. One line in the log, the whole budget burnt, 1 !== 2.

Reproduction, and the proof it is fixed

Making the stub take 1.5s to reach its first write reproduces CI exactly on this Mac, where it had never failed:

✖ ... (16086.608166ms)          # CI reported 16311ms
  scratch removed: true
  RECORDED STARTS: [["prompt", ... "--continue-run","--resume-session","sess-xyz"]]   # the CONTINUED run
  scratch events log:
  <no scratch events log>

With this change, that same simulation passes 3/3.

Why the wait is the right fix, not a sleep

A real bind cannot arrive before the run is up: the run writes it into its own event log (recordBind, cli.ts:1540; the dashboard only appends to the control file, which the run reads and then records). So a bind the daemon tails always comes from a live process. The test now models that by waiting for the topic run's start before binding it.

Also in here:

• the stub installs its SIGTERM handler before its first write, closing the last window where a re-home could kill it silently
• the test(the-framework): make the re-home failure say why #1166 diagnostic prints the recorded starts — "which spawn is missing" was the first question and it could not answer it, which cost a round of CI
• the poll ceiling drops 15s -> 10s and its comment now says what it is. Raising it never helped (6s, 30s, 15s all failed identically); it is a backstop, and it has to leave room for the three waits this test now makes inside the 60s per-test timeout

Not changed

No production change. spawnDetached runs process.execPath <bin> directly, so there is no intermediary child that can exit while the run lives on, and the "only tear down when the run has ended" guard the issue asks for already exists as the done check in tearDownTopicScratch.

Test-only, so no changeset. pnpm test in packages/the-framework: 1302 pass, 0 fail.