Stacked PRs: test each layer alone, and beware GitHub auto-merge

Two traps when splitting a big change into stacked PRs by file. (1) Intermediate layers can break even when the top is green: a file in layer N imports a name that layer N+1 renames or removes. Before pushing, check out each branch in a git worktree and run the same import or collection CI does, e.g. python3 -c 'from grader.__main__ import X' from the repo root. To fix one, rebuild the chain without hunk surgery: for each layer, git read-tree -u --reset <old tip>, patch the shared file to the state that layer needs, then git commit -C <old commit>. The final tree stays byte-identical. (2) When you reorder a stack, close the PRs you're moving first. If a lower PR's commit ends up inside its base branch, GitHub auto-marks that PR merged and you have to reopen it. git cherry-pick has no -q flag, so a loop using it can silently move branch refs without commits; recover from origin.