Speed up mirror checkouts: 100ms lock polling and snapshot-based commit verification

[lox]

Stacked on #4201 (which stacks on #4198). Two independent checkout-latency changes for mirror-enabled agents, benchmarked with real bootstrap checkout jobs against a 72 MiB repo behind a 300 ms-connect-latency proxy.

Scenario	main	#4198+#4201	this PR
Cold (empty mirror)	4.7s	3.9s	3.4s
Steady state (new commit per build)	1.9s / 4 conns	—	0.7s / 1 conn
Warm, same commit re-run	1.5s / 3 conns	0.6s	0.6s / 1 conn
8 parallel jobs, one mirror (makespan)	8.4s	7.6s	1.4s

1. Poll mirror locks every 100 ms

Shell.LockFile retried a held lock every second, but the mirror clone/update locks (its only callers) are typically held for single-digit milliseconds. The poll interval — not the lock — serialized same-host parallel jobs into ~N seconds for N jobs. Now 100 ms, with quieter logging: one line when waiting starts, one every 30 s while blocked, one with elapsed time on acquisition. The lock protocol itself (flock, path+"f") is unchanged, so mixed-fleet/shared-filesystem behavior is preserved.

2. Answer strict commit verification from the per-job snapshot when it can

Strict verification always fetched the canonical branch tip — even when this job's mirror update had just fetched exactly that tip. mirrorReference now records branchTipFresh: set only when this job synced refs/heads/<branch> from the canonical repository (fresh canonical mirror clone, or the warm-path branch fetch). When set, verification runs the ancestry check against the immutable per-job snapshot with no network. Only a definitive local positive short-circuits; any other outcome (missing ref, negative, command failure) falls through to the unchanged canonical fetch-based check.

Paths that cannot vouch for the tip never claim freshness and keep full canonical verification:

• mirror fetch skipped because the commit was already present (tip could predate a force-push)
• refs populated from a remote mirror (bulk clone or targeted hit)
• --git-mirrors-skip-update, submodule mirrors, tag builds

So the security posture of strict is unchanged; steady-state CI (a new commit triggers the build) just stops paying a canonical round-trip for information it already fetched. Re-running an old commit still makes the small canonical verification fetch, by design.

Soundness fix the freshness claim required

The warm-path mirror update fetched the branch by bare name. Git resolves a bare name against refs/tags/ before refs/heads/, so a tag sharing the branch's name was fetched instead and the mirror's branch ref silently stayed stale (reproducible on main today). The update now fetches +refs/heads/X:refs/heads/X explicitly, passed unsplit via a new RawRefSpecs field on gitFetchArgs because quotes are legal in ref names and shellwords.Split would mangle them. Tag builds (where BUILDKITE_BRANCH may name the tag) and pre-qualified refs/... branch values keep the historical bare-name fetch and never claim freshness.

Review notes

• Oracle-reviewed; its one blocker (the bare-name fetch could leave the claimed ref stale) is fixed as above and pinned by TestUpdateGitMirrorBranchTipFreshDespiteSameNamedTag, which fails against the bare-name fetch.
• Point-in-time semantics: a fresh-tip positive reflects a canonical observation made earlier in the same checkout (before maintenance/snapshot/fetch) rather than at the probe itself — the same class of check-then-use window the fetch-based probe already has, slightly wider. Documented on verifyCommitAgainstSnapshot.
• In a parallel fan-out on one commit, only the job that performs the branch fetch gets the fresh flag; the rest fall back to the ~650 B canonical fetch. Extending freshness across jobs would need shared state and a weaker invariant, so it's deliberately not done.

Validation: go test ./... (37 packages ok), golangci-lint run clean, gofumpt -extra clean. New tests: TestVerifyCommitAgainstSnapshot, TestVerifyCommitSnapshotShortCircuitAndFallback, TestUpdateGitMirrorBranchTipFreshDespiteSameNamedTag, TestUpdateGitMirrorNoFreshnessForTagBuilds.