serve: integration harness + fixes for --trackDeps over-reporting and JGit fetch failures

[tinder-maxwellelliott]

Summary

Hardens the bazel-diff serve query service. Adds a standalone integration harness that exercises serve end to end (which surfaced a real correctness bug), plus two fixes:

1. --trackDeps over-reporting — serve --trackDeps returned inflated /impacted_targets sets on cache hits.
2. JGit fetch robustness — the on-demand refetch added in fix(serve): resolve missing revisions via on-demand refetch #411 fails on shallow/partial clones with Missing delta base; it now falls back to native git.

The --trackDeps bug (commit 1)

TargetHash is a data class whose generated equals() includes the deps field, but TargetHash.fromJson (used to read cache entries) only parses type#hash~directHash and always leaves deps = null. So a cache-miss to (freshly generated, deps populated under --trackDeps) compared against a cache-hit from (deserialized, deps = null) reported every dep-carrying target as changed even when its hash was identical:

revisions	correct	before this PR
C1→C2 (both fresh)	{core, core.txt, mid}	✅
C2→C3 (from cached)	{core, core.txt, mid}	❌ + other
C2→C4 (from cached)	{other, other.txt}	❌ + core, mid

Anyone running serve --trackDeps (required for /impacted_targets_with_distances) got over-broad impacted sets on cache hits. The CLI never hit it (both sides deserialized → symmetric). Fixed by comparing hash identity (type#hash~directHash), not the full TargetHash, in computeSimpleImpactedTargets and computeAllDistances.

JGit fetch fallback (commit 2)

JGit 5.13 can't fetch shallow (--depth) or partial (--filter=blob:none) clones whose thin packs are delta-compressed against absent objects (Missing delta base <sha>) — the class of the reported production error. JGitClient.fetch() now retries with the native git binary (at --gitPath) on any in-process fetch failure, and warns once at startup if the clone is shallow/partial. JGit stays the default for resolve/checkout; --gitEngine=subprocess still skips the in-process attempt.

Repro caveat: I could not reproduce Missing delta base locally — JGit 5.13.3 negotiates shallow/partial fetches cleanly against a cooperative localhost git daemon; the real failure needs a real remote's repack state. The fix is therefore defensive-but-correct (it's exactly what --gitEngine=subprocess already does for the whole flow), and the harness's shallow/partial cases are engine-parity gates the fallback keeps green.

Harness + CI (commit 3)

tools/serve_harness.py drives the real binary over HTTP against a live git:// remote (git daemon) across both git engines × full/shallow/partial clones + the on-demand refetch path — coverage E2ETest#testServeEndToEnd (a single local --no-initial-fetch repo) can't reach. Run python3 tools/serve_harness.py (--only, --skip-build, --keep-artifacts, -v, --bazel).

Wired into CI as .github/workflows/serve-harness.yml, cron-only for now (12h schedule + workflow_dispatch) while it proves stable on runners; promote to push/PR gating later (one-line change, documented at the top of the workflow). Intentionally not a py_binary — a nested bazel run would deadlock on the output-base lock.

Testing

• Harness: 50/50 across the full matrix, via the exact CI invocation (--bazel).
• New unit tests: CalculateImpactedTargetsInteractorTest (deps-asymmetry, both endpoints), JGitClientTest (fallback-disabled surfaces the JGit error; both-fail names the native fallback; shallow-clone fetch).
• Full //cli suite green except 4 E2ETest sub-tests that need a system JDK for their nested local_jdk toolchain (environment-only, unrelated to this change) — testServeEndToEnd and the core get-impacted-targets tests pass.

🤖 Generated with Claude Code