Porch's post-merge state commits are stranded on every completed builder branch, and block worktree cleanup

[pseudoseed]

Porch writes chore(porch): <id> PR #N merged and chore(porch): <id> protocol complete after
the PR merges. They therefore cannot be in the merge, they land on a branch whose work is already on
main, and nothing carries them anywhere.

Three times in one night:

Project	Stranded commits
bugfix-214	a725af68f — carried on the #216 PR with a disclosure line
air-220	63fb7a532, ae9956898 — cherry-picked onto air-219's branch
air-219	f845ab590, fdbd50c81 — still stranded

Two distinct costs

1. The project record on main is wrong. Without those commits,
codev/projects/<id>/status.yaml on main says the project sits at the pr phase with nothing
after it — untrue of a completed, merged project. It is bookkeeping, and it is still a record that
misstates what happened.

2. afx cleanup refuses the worktree, correctly. The branch tip is not an ancestor of main,
so cleanup preserves the worktree and branch rather than destroying unmerged commits. That is the
right behaviour and it means every completed builder leaves a worktree behind, which then reads
like a live builder to the next person looking at .builders/.

Both air-219 and air-220 are sitting in .builders/ right now for exactly this reason, with
their work fully merged.

Why the obvious fixes are wrong

• A follow-up PR is what porch itself refuses (porch declares PROTOCOL COMPLETE while the builder branch is still ahead of main #57): unmodelled, no phase, no gate, no
  notification, so nobody learns a builder is waiting on it.
• Committing straight to main puts unreviewed commits on the default branch. The argument for
  it is good, which is precisely why the rule exists.
• Dropping them leaves the record wrong, permanently, and the worktree still cannot be cleaned
  because the commits exist on the branch regardless.
• Cherry-picking onto a sibling builder works and is what was done tonight, but it needs a
  sibling that is still open, that has the target status.yaml in its history, and an architect
  awake to sequence it. None of those hold in the general case.

The shape of a real fix

The state write and the merge need to stop being two events on two different refs. Options worth
weighing, none decided here:

• Porch writes the completion state into the PR branch before the merge, deriving "will be
  merged" from the gate rather than observing it afterwards — accepting that a merge that then fails
  leaves a wrong record, which is the trade to argue about.
• Porch pushes those commits directly to main itself, as a tool operation with its own audit
  trail, rather than leaving an agent to smuggle them through a PR.
• status.yaml for merged projects stops living in git on the branch at all.

Also worth fixing regardless

afx cleanup should say why it preserved a worktree, naming the unmerged commits. Today it
reports Worktree preserved (unmerged) and leaves the reader to find out that the only unmerged
commits are porch's own bookkeeping — which is a very different situation from real unmerged work,
and the two currently read identically.

Found while merging spec 146 phases 9 and 11 (#221, #224).

[pseudoseed]

Hit 4 times in one afternoon: air-271, bugfix-242, bugfix-260, bugfix-278. Each needed a second PR carrying one file, and each of those PRs needed origin/main merged into the branch first or it would have shown unrelated merged work as deletions. bugfix-260 measured that: without the merge its PR would have been 50 files and 60 deletions instead of 1 file and 12 insertions.

The part worth recording

From bugfix-260, and it is the observation that changes the shape of the fix:

all three commits were written after #285 merged, which means no PR could ever have carried them. Porch records the merge, the gate approval and protocol completion into status.yaml at moments that all fall after the branch's own PR is gone. It is not a race that a well-timed builder avoids.

So this is not a timing problem, and no discipline on the builder side fixes it. The three writes are, in order: PR merged, pr gate approved, protocol complete. All three are by definition after the PR that would have carried them.

What that rules out

Any fix of the form "commit state earlier" or "hold the PR open longer". The state does not exist yet at the only moment a PR could take it.

What it leaves

• Write post-merge state somewhere that is not the builder branch. The project state for a merged project belongs on main, and the branch is the wrong place to author it.
• Or have porch open and merge the follow-up itself, so the second PR is machinery rather than a task handed to a builder and then to an architect.
• Or stop writing those three transitions to a tracked file at all, and keep post-merge project state where porch status already reads it from, without a commit.

The current cost is two PRs and two review round trips per project, plus an architect who must remember that afx cleanup on a project porch calls "complete" will otherwise strand a file.