feat(relay): inventory unreachable Git objects (relay-only reland of #2264)

Reland of #2264 (reverted in #2275), trimmed to buzz-relay only per review:

- Dropped all Helm chart changes (deployment.yaml, values.yaml,
  values.schema.json). The worker is configured entirely via
  BUZZ_GIT_GC_* env vars with safe defaults (disabled); operators can
  opt in through the chart's existing relay.extraEnv. Dedicated chart
  knobs can land later as a deploy-only change.
- Dropped the Hermit helm 3.16.4 pin (bin/helm) — it existed only to
  lint the removed chart changes.
- Dropped the buzz-db rename (UsageMetricsLeader -> AdvisoryLockLeader).
  The GC worker reuses the existing try_lock_usage_metrics(lock_key)
  API with its own advisory lock key; the rename is deferred.

The opt-in worker elects one relay replica via a Postgres advisory
lock, marks objects reachable from every current repository pointer,
and inventories the shared manifests/, packs/, and idx/ namespaces,
exporting candidate counts, bytes, scan freshness, and completeness
metrics. Bounded pointer count, listed objects, manifest transfer, and
wall-clock duration. Dry-run only: nothing is ever deleted, and the
worker does not start unless BUZZ_GIT_GC_ENABLED=true.

Co-authored-by: Thomas Petersen <thomasp@squareup.com>
Signed-off-by: Thomas Petersen <thomasp@squareup.com>

docs/git-on-object-storage.md

@@ -158,6 +158,17 @@ assumption for any S3-compatible backend.
   orphaned could 404 a concurrent reader mid-hydrate — see Theorem 2's reliance
   on every named pack being GETtable.)
 
+  The relay includes an opt-in, leader-elected **dry-run inventory** for this
+  future GC (`BUZZ_GIT_GC_ENABLED=true`). It lists only `manifests/`, `packs/`,
+  and `idx/`, computes reachability from every current `repos/*/pointer`, and
+  exports observed candidate counts and bytes. Pointer count, listed objects,
+  manifest bytes, and scan duration are bounded; truncated prefix inventories
+  are explicitly reported as incomplete. It never deletes. A candidate report
+  is not a deletion proof: production reclamation additionally requires
+  durable evidence that an object stayed unreachable longer than the maximum
+  read lifetime and coordination preventing a concurrent publisher from
+  making an old content-addressed object reachable during sweep.
+
 - **(A2) Strong read-after-write.** A read issued after a successful `PUT`
   observes that write. (AWS S3 provides this for all regions and all
   PUT/DELETE.)