subagent-driven-branch-ref-froze-stranded-commits

Confirm the strand by comparing `git rev-parse HEAD` with the branch ref in the worktree, then branch from `origin/main` and cherry-pick each verified missing commit oldest-first by full SHA. Run tests against the combined tree and ship a recovery PR that also fixes any path drift from intervening PRs.

`git log` walks from HEAD, so it shows commits made on a detached HEAD that never updated the named branch ref. The push ships only the branch ref, so the squash merge captures the truncated tree while the extra commits remain stranded in the worktree.

Check that `git rev-parse HEAD`, `git rev-parse <branch>`, and `git rev-parse origin/<branch>` all return the same SHA, and that `git log origin/<branch>..HEAD --oneline` prints nothing. Adding `git symbolic-ref HEAD || echo DETACHED` to each subagent's opening diagnostic catches detachment before the first commit.

The reflog gap is when `git reflog show <branch>` ends earlier than `git log --oneline` on the same worktree. Because detached-HEAD commits never update the branch ref, the reflog records only what the ref actually saw, and the difference is exactly the stranded zone.

No. GitHub's merge button operates on the remote branch state exactly as pushed, so a mismatch between local worktree HEAD and the pushed ref is invisible. The PR-body file count exceeding `gh pr diff <N> --name-only | wc -l` is a useful secondary canary.

Avoid `oldest..newest` ranges because they exclude the oldest commit, and inspect merge commits separately since cherry-picking one requires choosing a mainline parent. Cherry-pick each verified SHA explicitly, oldest first, to preserve a clean audit trail.