Spec 146: no evidence that porch's own orchestration drives a protocol over a thread

[pseudoseed]

Split out of #235 (Spec 146 Phase 10) rather than grown into it. Raised by the codex review
lane on #238, and there is no rebuttal available: I looked for a later phase in
codev/plans/146-codev-client-on-t3code.md that picks it up and there is none — 11 and 12 are
the client tree and tiling, 13 is extension retirement, 14 and 15 delete the terminal layer.

What is missing

Phase 10's harness runs a complete BUGFIX protocol on a t3code thread — spawn, three phases,
checks between turns, a real one-hour gate, PR, merge — and every step happens. But it
reenacts the protocol rather than driving porch through it. Specifically it:

• never loads protocol.json at runtime,
• performs no porch phase transition (porch check / porch done),
• requests and approves no gate; the gate is a sleep in the runner.

So the evidence in codev/research/146-phase10-live-evidence.json can stay green while porch's
orchestration over a thread is broken, or while the protocol's own definition changes in a way
the harness does not follow.

What Phase 10 did close

spec-146-phase-10-full-protocol.test.ts derives the phase ids, the fix phase's checks and the
pr phase's gate from codev-skeleton/protocols/bugfix/protocol.json and asserts the runner
enacts each. A phase added, renamed or removed there now fails the test.

That is a guard against the definition drifting away from the harness. It is not a demonstration
that porch drove anything, and the two should not be confused.

Why it was not fixed in #238

The Phase 10 deliverable enumerates the steps — "spawn, phases, checks between turns, a gate that
pauses at least one hour, PR, merge" — and all of them run, so the deliverable is met as written.
Driving porch's own phase machine and gate lifecycle over a thread is a larger piece of work with
its own design questions (which process owns the porch state, and how a gate approval reaches a
thread-backed builder given that --no-enter is terminally refused on threads — see #221), and
it does not belong inside an AIR.

The blocker inside this, which nobody owns today

This is not only "we lack a test". There is a live gap underneath it, left open by #221:

• --no-enter is terminally refused on threads. thread.turn.start IS the submit, so there
  is no composer to stage a message into and nothing to leave sitting unsent.
• Porch gate notifications use --no-enter, precisely because a gate notice is meant to sit
  until a human decides.

Put together: a thread-backed builder cannot be told that its gate is waiting. The
notification has nowhere to land. That is the reason thread-backing cannot be turned on for any
workspace that receives gates, and it is why the porch-orchestration test above cannot simply be
written today — the gate half of the lifecycle has no delivery mechanism to exercise.

Nobody owns this. #221 identified --no-enter as terminally refused and fixed the case where it
silently became a submitted turn; it did not answer what should happen to a gate notice bound for
a thread. That question is the first thing this issue needs decided, ahead of any test.

Suggested shape

A protocol run where porch is the driver: porch next / porch check / porch done against a
thread-backed builder, with the pr gate actually requested and approved, asserted end to end.
The existing tools/t3-server/full-protocol-run.sh and the pinned-server harness are reusable;
what is new is the porch side.

Refs #235, #238

Related: #227 (thread-path parity: interrupt/cleanup still throw on threads).