A second commit to a change becomes its head (take two, from the branch that exists) #252

Pushed successfully.

A same-repo pull's head_oid was only ever written when the pull was opened (or merged) — the cross-repo case gets refreshed on every push by core/following.ts, but a same-repo pull's own branch moving never touched the row. So a second commit to a change's branch — through the web editor, commitToBranch, or an ordinary git push — left the row naming the first commit forever, even though the branch, the deploy, and the diff had already moved on, and Studio's Look card called a current look "moved".

Added trackPullHead (src/core/pulls.ts) as the one updater: it writes the branch's new tip onto the open, same-repo pull whose head that branch is. It's called from editFiles, commitToBranch, and the post-receive hook in src/http/server.ts — the same three seams that already land a commit and announce a "push" — each one calls it before emitting that event, so a check or a deploy triggered downstream never races a stale row.

test/web-editor.test.ts now commits twice to a change's branch through the editor, asserts getPull(...).headOid equals the second commit, and asserts the studio page no longer calls a look of that head "moved." Verified it fails on the pre-fix code and passes with the fix.

Ran the full forge.json check suite (tsc --noEmit plus all 22 named test files): 407 tests pass, none fail — the "check is red" problem mentioned in the issue is tracked separately and wasn't reproduced here.

This is the same fix that was written on the now-gone branch for #232/#220, reconstructed from that pull's diff and applied fresh to current main.

🤖 Generated with Claude Code

Closes #234