Spec 146 phase 9: six call sites treat a thread-backed builder as not running

[pseudoseed]

Surfaced by the two-lane integration review of PR #166 (phase 8). Filing now so it is not rediscovered after it starts causing damage.

The problem

Six call sites use "has no terminal_id" as their test for "is not running". A thread-backed builder has no terminal_id by design, so every one of them reads a live builder as a dead one:

• status.ts:84 — isRunning = !!builder.terminalId
• attach.ts:59
• cleanup.ts:563 — will not kill it
• stop.ts:78 — will not stop it
• reset.ts:125 — builds a TerminalPort regardless
• the afx send render gate, which needs a live PTY

All six are inert today, because no spawn thread factory is registered and chooseSpawnPath always returns pty. The moment phase 9 registers one, afx stop will report a thread-backed builder stopped while it keeps running, and afx cleanup will report it cleaned while its work continues.

Why it must not be left to degrade

Each of these fails by doing nothing and reporting success. That is the exact failure mode spec 146 phase 5 exists to eliminate, and it would be reintroduced one layer up: a command that cannot act on a thread-backed row must not be spelled the same way as a command that acted and found nothing to do.

Each site should throw "thread-backed, unsupported here" until phase 9 gives it a real implementation. A loud unimplemented beats a quiet lie.

Second item for the same phase

Worktree spawn writes .builder-start.sh and then skips createPtySession on the thread path. Whatever factory phase 9 registers has to launch that session, or the worktree spawn path starts nothing at all.

Related

• PR [Air #163] feat: write thread_id at spawn in status.yaml and global.db #166 implements phase 8 and is where this was found.
• The rollback lever setThreadBackedSpawnsEnabled currently has zero production callers. Wiring it to .codev/config.json belongs in this phase or later, not in phase 8.