Reduce VCS remote-status polling cost

[badcuban]

Priority: P1

Why

Source-control remote status polling is one of the largest real slow-span groups in the server trace. Even when it succeeds, repeated git fetch --quiet --no-tags work can add visible latency and background load, especially on Windows.

Diagnostics evidence

From C:\Users\Will\.t3\userdata\logs\server.trace.ndjson* on May 26, 2026:

• VcsStatusBroadcaster.refreshRemoteStatus: 81 spans over 1s, average about 3.2s, max about 9.4s.
• remoteStatus / readRemoteStatus: 80 spans over 1s, average about 3.0s.
• GitVcsDriver.fetchRemoteForStatus: 67 spans over 1s, average about 1.4s, max about 3.9s.
• Code currently has a default VCS status refresh interval of 30s and an upstream refresh interval of 15s.

Acceptance criteria

• Remote status refreshes are coalesced per repo and do not duplicate work across subscribers.
• Background fetches back off or become less frequent when the repo is idle, the network is slow, or the UI does not need fresh remote data.
• The UI can show stale cached remote status without blocking source-control actions.
• Add trace or test coverage proving refreshes are throttled/coalesced.

[badcuban]

Backlog triage update: this is prioritized for the next practical release because the project direction is now personal local-tool reliability/performance/UX rather than public marketing or hosted web. This should stay near the top as a direct performance/background-load issue.

[badcuban]

Closed after verification on main (a8e4e801): VCS remote status refreshes are cached/coalesced, ref-counted per repo subscription, back off on failures/unchanged results, can be disabled, and have coverage for backoff and poller shutdown.