Thread path: a process-global spawn factory in Tower, interrupt/cleanup still broken, and two smaller seams

[pseudoseed]

Four things #221 found, verified, and deliberately did not fix, so that PR could stay what it is:
proof of #179 items 3 and 4 plus the instrument bugs that made them unrunnable.

Listed in the order they will bite.

1. installThreadSpawnFactory writes a process-global from Tower's process

ensureThreadBackendReady calls it on every successful init, and Tower now calls that for every
workspace it delivers to. setSpawnThreadFactory is a module-level singleton, so the last
workspace to connect owns it.

This is the bug the per-workspace engine map just fixed, one door down. It is unreachable
today only because chooseSpawnPath's single consumer is afx spawn, which is one workspace per
process. The factory at least closes over the workspace it was installed for, so it dispatches to
the right engine — but the selection of it is global, and the first thing that reads
chooseSpawnPath inside Tower will find whichever workspace connected last.

Fix: key the spawn factory the way the engine map is keyed, or stop installing it from a
multi-workspace process.

2. afx interrupt and afx cleanup are still broken on the thread path

Both reach getThreadEngine(workspaceRoot) in a fresh process where nothing has registered one,
so both throw. #221 made them throw about the right workspace and with a message that names the
limitation, which is honest but not working.

The delivery path shows the shape: register the backend in this process, attach the thread from
the row, then act. attach exists now; neither command calls it.

3. An architect's attach carries no harness or model

mailbox-wiring.ts builds a ThreadDeliveryContext for an architect with no harness/model,
so attach falls back to the engine's defaultHarness / defaultModel. The builder path is
right — it reads harness and model off the builder row — but the architect table has no such
columns, so there is nothing to read.

It therefore depends on the workspace's configured defaults being the same at attach time as they
were at create time. Change the threads.model in .codev/config.json between a spawn and a
delivery and the resumed thread runs under a different model than it was created with, silently.

Fix: record harness and model on the architect row, the way builders does.

4. activeProjectForWorkspace hand-builds a second auth path

A bare fetch with an authorization: Bearer header, in thread-backend.ts, next to
@cluesmith/t3-client/auth which owns every other request to that server. It works and it is one
request, but the knowledge of how this server is addressed now lives in two places, and the
client is where it belongs.

Filed from #221's round-4 review, per the architect's scope line: blocking means Tower-wide,
destructive, or user-visibly false; everything else gets an issue.

[pseudoseed]

Adding one from #221's round-6 review, with the architect's ruling.

ownsProcess does not identify the executable

tools/t3-server/t3-server.mjs classifies a process as this harness's own server when its argv
contains a bare serve argument and --base-dir <our data dir> as a real argument pair. It
does not check what the executable is. Any command matching those two conditions is treated as
owned, and stop will SIGTERM its process group.

Ruled non-blocking on #221, and I agree with the reasoning:

• The residual is contrived rather than real. The version this replaced matched
  cmd.includes(runtimeDir), which tail -f <runtimeDir>/server.log satisfies — something a
  person actually does. Matching the current check requires serve plus --base-dir pointing at
  one specific repo's tools/t3-server/.runtime/data, and essentially nothing but this harness
  uses that path.
• The docblock no longer claims a proof it does not perform — it says "argv heuristic, not proof
  of parentage" — which was the actual defect that blocked.

I was asked whether I had a counter-case that should make it block. I do not.

Shape of the fix: compare the executable as well — the harness knows the interpreter it
launched (T3_NODE) and the pinned CLI path, so it can require that the command starts with one
of them rather than only that the arguments look right. ps -o command= gives argv; ps -o comm=
gives the executable, and the two together are a narrower claim than either alone.

[pseudoseed]

Correction on installThreadSpawnFactory: the fix is to DROP the call, not to key it

This issue lists installThreadSpawnFactory writing a process-global from Tower's
multi-workspace process, with "key the spawn factory the way the engine map is keyed" as the fix
shape. That is the wrong answer, and #221's round-9 review (claude lane) has a better one.

Keying it does not help, because the problem is not which workspace the factory serves — the
factory already closes over the workspace it was installed for. The problem is where it is
installed from. ensureThreadBackendReady runs in the afx CLI and in Tower, and it cannot
know which. In the CLI, installing a process-global spawn factory is exactly right: one process,
one workspace, one spawn. In Tower it is meaningless at best — chooseSpawnPath's only consumer
is afx spawn, which never runs there — and a latent cross-workspace global at worst.

So the fix is to drop the call from ensureThreadBackendReady and install the factory from the
CLI spawn path, which is the one place that knows it is a CLI process about to spawn. A function
that behaves differently depending on which process it is in should not be guessing; the caller
that knows should tell it.

That also removes the last process-global in this subsystem that is written from Tower, which is
the point of the recorded observation about the four test-only exports.

Correcting my own fix shape, from #221's review.

[pseudoseed]

Also: afx send to a thread-backed agent always reports pending

From #221's round-9 review (opencode lane). Not a defect — it is the async design working — but it
is incomplete, and worth writing down before someone reads it as a bug.

The request path enqueues, triggers a drain, and re-reads the row. Since #221 the thread branch
does not await thread.turn.start: the submission runs out of band so one unresponsive server
cannot stall Tower's sequential drain loop for every other workspace. The row is therefore still
held when the route reads it, so afx send reports held with no reason, which the CLI renders
as pending — every time, even when the turn starts a moment later and succeeds.

So a sender to a thread-backed agent never learns from the command whether the turn actually
started. afx inbox shows the row clearing, and Tower's log names the outcome, but the send
itself always says the same thing.

The honest fix is not to await the submission — that reintroduces the Tower-wide stall. It is
either to report the row's subsequent fate (the CLI polling briefly, or the route waiting on a
bounded settle) or to say plainly in the CLI output that a thread-backed send is fire-and-forget
and where to look for its outcome. Both are decisions rather than obvious calls, which is why this
is filed rather than fixed.

[pseudoseed]

Cross-link: #240 — no evidence that porch's own orchestration drives a protocol over a
thread, filed out of Spec 146 Phase 10 (#235 / #238).

It belongs next to this issue rather than floating on its own, because it contains the design
question this one's neighbourhood left open. --no-enter is terminally refused on threads
(thread.turn.start IS the submit, so there is no composer to stage into), and porch gate
notifications use --no-enter — so a thread-backed builder cannot be told that its gate is
waiting. The notice has nowhere to land.

That is the reason thread-backing cannot be turned on for any workspace that receives gates, and
it needs deciding before the porch-orchestration test #240 asks for can be written at all: the
gate half of the lifecycle currently has no delivery mechanism to exercise.