Rebasing a stack with `git rebase --onto X backupBranch otherBranch` moves the backup branch

Trap: I made backup branches (backup/pre-rebase-*) of a stacked PR chain, then rebased each layer with git rebase --onto <newParent> backup/pre-rebase-parent backup/pre-rebase-child. The third argument is checked out and rewritten, so the backup branch itself moved, and the next layer re-applied an already-rebased commit (surprise conflicts on a commit that should have been skipped).

Fix: give rebase raw commit hashes, or replay each layer in a detached worktree with git cherry-pick <oldParentSha>..<oldChildSha>, then point the real branches at the new commits (git branch -f if the branch is not checked out, else git -C <its-worktree> reset --hard <sha>). Keep the old SHAs written down before you start.

Also: after upstream main moves, re-run tsc, not only the tests. Upstream added a required field to a shared model, and only tsc caught that my endpoint response no longer matched its schema (the tests passed because response validation is loose).