[bug] Repository sync silently succeeds but indexed content is stale after branch rename/deletion

[Akhilesh29]

Describe the bug

After renaming or deleting a branch on the remote (GitHub/GitLab), Sourcebot's
next sync cycle completes without any errors in the logs, but the old branch
name continues to appear in the code search UI and the file explorer. The stale
branch remains fully searchable and navigable as if it still exists, with no
indication to the user that it has been removed upstream.

This is different from #248 (token rotation not reflected in cached remotes) —
here authentication is fine, the sync job runs successfully, but the
branch-level index is not pruned after a remote ref disappears.

Logs: Backend logs during the affected sync cycle (no errors shown despite stale
branch remaining):

[backend] | 2025-12-10T08:22:11.412Z info: [main] Fetching my-org/my-repo...
[backend] | 2025-12-10T08:22:12.103Z info: [main] Successfully fetched my-org/my-repo
[backend] | 2025-12-10T08:22:12.110Z info: [zoekt] Indexing my-org/my-repo...
[backend] | 2025-12-10T08:22:14.887Z info: [zoekt] Successfully indexed my-org/my-repo

To reproduce

1. Deploy Sourcebot via docker compose up with a GitHub connection indexing
   at least one repo that has multiple branches configured.
2. Confirm the branch (e.g. feature/old-name) is visible and searchable in
   the Sourcebot UI.
3. On GitHub/GitLab, rename or delete that branch.
4. Wait for the next sync cycle to complete (or trigger a manual re-index).
5. Observe the logs — sync completes with no errors.
6. Return to the Sourcebot UI and search for content that only exists on the
   deleted/renamed branch.

Sourcebot deployment information

Sourcebot version (e.g. v3.0.1): latest (v4.10.30)

Additional information

• The issue persists across container restarts — the stale branch is still
  indexed after a full restart of the stack.
• Workaround: manually deleting the Zoekt index data under the
  /data/.sourcebot volume and allowing a full re-index clears the stale
  branch, but this is disruptive for large repos.
• This may be related to how git fetch is called during sync — if
  --prune is not passed, deleted remote refs are not removed from the
  local clone's ref list, and Zoekt re-indexes whatever refs it finds locally.