Summary

Closes #638.

av sync fails when a stack has more than 20 PRs because GitHub rejects pushes with more than 20 ref updates. The reporter's workaround was manually pushing a few branches to drop under 20 before letting av sync finish.

This splits pushCandidates into chunks of 20 and runs git push --atomic --force-with-lease=... once per chunk. Each chunk is still atomic on its own; only the whole-operation atomicity is relaxed, which is the intended trade-off (no other way to make >20-branch stacks pushable at all).

Files

• internal/gh/ghui/push.go:
  • New gitPushChunkSize = 20 constant with a comment pointing at Batch updates (hitting gh branch update limits) #638.
  • runGitPush now loops start += gitPushChunkSize over vm.pushCandidates, building per-chunk pushArgs and calling vm.repo.Run once per chunk. Each chunk includes its own --atomic and per-branch --force-with-lease= so safety guarantees inside a chunk are unchanged.

Verification

• go build ./... clean.
• go vet ./... clean.
• go test ./internal/gh/ghui/... passes (no test files in this package, returns "no test files").
• The pre-existing typecheck warning in internal/gh/ghui/push.go:553 (mapToRemoteTrackingBranch undefined) reproduces on master without these changes and is not introduced by this PR.

Test plan

• go build ./... clean.
• Stacks with <= 20 branches still push in a single chunk (loop runs once).
• Each chunk uses --atomic + --force-with-lease=, preserving safety inside the chunk.
• Manual: run av sync on a stack with > 20 PRs and confirm all branches push without the GitHub limit error (no fixture in this repo's tests).

Notes

• Cross-chunk atomicity is relaxed by design. If the first chunk pushes successfully and the second fails, the user is left with a partial push. Same observable behaviour as the reporter's manual workaround.
• 20 was chosen because it's the documented GitHub limit; if GitHub ever raises it, the constant is the only knob to change.