Rolling upgrade: GitHub default-branch adoption can miss the first sync or an older replica's PATCH to main (#599 follow-up) #609

Problem

PR #607 adopts the GitHub default branch at a successful sync of a GitHub sync repo whose create omitted default_branch (#599). During a rolling upgrade from a release without this rule, two cases miss the upstream behavior. http-api.md documents both, and the PR's Codex round 1 raised both.

1. A sync that an older worker runs does not adopt. The flag stays set, so the next sync by an upgraded worker adopts. Until that sync, the repo is on main, and with no further trigger it stays there.
2. An older replica's PATCH /repo to main before that sync writes nothing that differs from the create's placeholder main. The next sync by an upgraded worker then replaces the caller's explicit main with the GitHub branch. A PATCH to any other branch is kept, because the adopt write requires the repo to still be on main.

Possible fixes

• A fleet-version gate, like OPENSTORAGE_SYNC_STEAL_LEGACY: an operator assertion that no older replica remains before creates set the flag.
• A reconciliation sweep that schedules a sync for flagged repos with success_count > 0. This covers case 1 only.
• Deploy sequencing in the release notes: upgrade every replica before accepting GitHub sync creates.

Trigger

Act on this issue at the first report of a GitHub sync repo left on main after a rolling upgrade, or when a release that ships #607 is prepared (decide then whether the release notes need a sequencing note).

Refs #599

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high