fix(git-sync): measure ahead_working against the agent's own branch (#2105)

[dolho]

Summary

_dual_ahead_behind_payload (agent server, docker/base-image/agent_server/routers/git.py) measured the working tuple against origin/<current_branch> only for trinity/* branches. Every other branch got the origin/main counts under the ahead_working / behind_working label. fleet_audit_service reads ahead_working as unpushed commits, so a fleet renamed to asus/* reported ~9,000 unpushed commits while the true gap was 0.

• Fix: the working tuple is measured against origin/<current_branch> whatever the branch is named. The prefix gate is gone.
• No upstream (a branch that was never pushed, or a detached HEAD): ahead_working counts the commits that no remote holds (rev-list HEAD --not --remotes), and behind_working is null. A detached HEAD is never compared with origin/HEAD, because that is the default branch, not the agent's.
• Unknown means null, never 0. This is the second field report on the issue: a master repo with no main read 0 ahead for 7 days while one commit sat unpushed. Now the working tuple reports 1, and the main tuple (plus the legacy ahead / behind aliases) is null rather than a believable 0. Consumers are already null-safe: sync_health_service._coerce_counter stores null as 0, and the UI checks > 0 or || 0.
• _compute_ahead_behind (the conflict classifier's best-effort (0, 0)) is unchanged.

This unblocks the numbers that trinity-enterprise#706 (divergence age) and #707 (sync surfaces) key on.

Tests

• tests/unit/test_git_status_dual_ahead_behind.py: 5 new tests over real git repos:

  • a pushed asus/* branch far from main reports 0 unpushed
  • unpushed and peer commits on a non-trinity/* branch
  • a master repo with no main
  • a never-pushed branch
  • a never-pushed trinity/* branch

• Mutation check: with the pre-fix function restored, 5 of 12 go red.

• Related suites: 197 passed (sync health, fleet audit, sync state, bug: git auto-gc can never complete inside agent containers — unbounded, silent workspace .git bloat (273GB observed; 97%-garbage repos) #1595/bug: git-sync agent workspaces grow unboundedly — auto-committed data churn bloats .git (44GB observed on one agent) #1596 signals, git status / bug(sync-health): the 60s poller takes .git/index.lock ~2×/min in every agent workspace and orphans a 0-byte lock on churn — silent commit failures fleet-wide #2742).

• Live check inside a running agent container on the local instance. I loaded the patched module beside the installed one; the running server was not modified. It ran read-only against the real workspace, and against throwaway repos for the rename case. Fields are [ahead_main, behind_main, ahead_working, behind_working]:

  case	old	new
  real workspace on main	[0,0,0,0]	[0,0,0,0]
  asus/* pushed, in sync	[5,0,5,0]	[5,0,0,0]
  asus/* + 1 unpushed	[6,0,6,0]	[6,0,1,0]
  never-pushed branch cut from it (1 commit on no remote)	[6,0,6,0]	[6,0,1,null]

Notes

• Base-image change: it takes effect on an agent after the base image is rebuilt and the agent is recreated.
• Worst-case budget: the status computation can now run up to 2 more git children (+20 s nominal). It is still capped by the existing 90 s leader deadline (bug(sync-health): the 60s poller takes .git/index.lock ~2×/min in every agent workspace and orphans a 0-byte lock on churn — silent commit failures fleet-wide #2742). The budget notes in the docstring and in feature-flows/git-sync-health.md are updated.
• Out of scope (noted on the issue as adjacent): sync_status: "pending_sync" on in-sync workspaces, and git_sync returning files_changed: 0 for committed-but-unpushed work.
• Independent of the stacked git-sync PRs. It is based on dev, and fix(git-sync): auto-sync heartbeat fetches and rebases before push; refuses on a shared source-mode branch (#3011) #3016 / feat(git-sync): an agent created as an agent owns its repository (trinity-enterprise#705) #3020 / feat(git-sync): the container pulls origin on its own (trinity-enterprise#703) #3021 don't touch this function.

Fixes #2105

🤖 Generated with Claude Code

[vybe]

merge-train: pushed two commits to this branch (mechanical, no change to the fix's intent):

1. Merged dev (picks up fix(ci): cap test SQLAlchemy below 2.1 — pg-migrations broke on the new default driver #3015's SQLAlchemy cap).
2. docker/base-image/agent_server/routers/git.py status route: sync_status now reads (ahead or 0) == 0. ahead aliases the main tuple, which this PR makes None on a repo with no main; None == 0 is false, so a clean, fully pushed master repo flipped from "Synced" to "Changes pending" in GitPanel.vue. This restores dev's behaviour on that one line.

Follow-up for you, not a blocker: should sync_status be derived from the working tuple instead of the main alias? That's a design call, so I left it. Also noted by validation: the detached-HEAD branch of _dual_ahead_behind_payload has no test.

Riding the current merge train.

[vybe]

merge-train: batch validated on train/20260925-1608 (#3027, full suite green).