Remove-MergedWorktrees.ps1 reaps a freshly cut branch worktree before its first commit #424

What happens

scripts/Remove-MergedWorktrees.ps1 -WhatIf run right after git worktree add -b <new-branch> <path> origin/main reports:

sweep: WOULD remove <worktree-root>/<new-branch> -- merged PR via commit association

The new branch has no commits of its own, so its tip is origin/main's tip. Tier 4 (gh api repos/<slug>/commits/<sha>/pulls) finds the merged PR that produced that main commit and treats the branch as merged.

Where

scripts/Remove-MergedWorktrees.ps1, tier 4 (around the merged PR via commit association line). The tier 3 comment states the intent ("A named branch never qualifies here; it needs positive PR evidence so a freshly-cut work branch is never reaped"), but tier 4 still reaps it.

Impact

A clean worktree that an agent has just created and not yet edited can be deleted by a concurrent sweep (for example another agent's loop iteration) between worktree add and the first edit. No committed work is lost, but the agent's setup breaks mid-task.

Expected

A named branch whose tip is reachable from origin/main (no commits of its own) is not treated as merged by commit association. Only commits that are not on main, or are a PR head, count as evidence.

Acceptance criteria

• The sweep keeps a branch worktree whose tip equals or is an ancestor of origin/main, unless tier 1 (merged-PR head branch name) matches.
• A regression test covers this case.