SAFETY-adjacent: an architect created by afx lands with codev_role empty, so spec 250's tree can never show a real architect

[pseudoseed]

What happened, on real hardware

afx workspace add-architect --name lan, against the fork's server on ~/.t3/dev, running the
merged spec 250 code:

$ sqlite3 ~/.t3/dev/state.sqlite \
    "select thread_id, coalesce(nullif(codev_role,''),'(none)') from projection_threads;"
2e2bd2c7-3ae7-4582-9d60-673da525a93f|(none)

The thread is created. codev_role is empty. So the sidebar renders it as an ordinary thread,
not as an architect, and nothing can ever be nested under it.

The command also did not return within 2 minutes, and afx status shows no new architect
registered — only the terminal-backed main.

Why this matters more than one empty column

Spec 250's entire tree is keyed on codev_role and codev_parent_thread_id. Every screenshot
that proved the hierarchy used seeded fixture threads with those columns written directly.
This is the first time the production path was run, and the field the whole feature depends on
does not arrive.

What is verified, and what is not

Verified by reading the merged tree:

• commands/workspace-add-architect.ts:98 calls createArchitectThread.
• thread-runtime.ts:425-431 passes role: 'architect' into engine.create.
• porch-driver/src/thread.ts:433 puts role on the create payload when it is defined.

So the role is supplied at every layer I checked. I have not identified where it is lost —
candidates are the server's create handler, the event payload, or the projection writer. Not
guessed at here.

The shape

This is the same defect the spec 250 review document calls "the costumes": a value asserted at the
decider, asserted in the projector, and never once carried end to end through a real server into
the projection by the command a human actually runs.

Suggested first test, and it should exist regardless of the fix: create an architect through
createArchitectThread against a live fork server, then read codev_role back out of
projection_threads. Fail it by reverting the field.

Reproducer

# fork server on ~/.t3/dev, .codev/config.local.json pointing at it
afx workspace add-architect --name lan
sqlite3 ~/.t3/dev/state.sqlite "select thread_id, codev_role from projection_threads;"

Refs #250.

[pseudoseed]

Closed by #274, merged as 7185088.

The reported symptom had a different cause than the title says. The role is not lost in this tree. The globally installed CLI was a pre-spec-250 build whose porch-thread-engine.js never forwarded input.role, so the fix on any given machine is pnpm -w run local-install.

What #274 actually landed: the closeThreadBackend release so afx workspace add-architect exits instead of hanging on an open WebSocket, afx status sourcing thread-backed architects from state rather than from the terminal list, and a unit test at the seam asserting createArchitectThread hands role: 'architect' to engine.create.

#276 covers the same thread-backend hang still present in afx spawn.