Trace GC sweeps and (opt-in) health probes

Co-Authored-By: Claude <noreply@anthropic.com>

docs/plans-executions/2026-08-24-1025-otel-tracing.md

@@ -8,7 +8,7 @@ Plan: `docs/plans/2026-08-24-1025-otel-tracing.md`
 - [x] Step 4 — `cmd/main.go` wiring
 - [x] Step 5 — Reconciler spans
 - [x] Step 6 — Discovery server
-- [ ] Step 7 — GC + health
+- [x] Step 7 — GC + health
 - [ ] Step 8 — GCP wire-log enrichment
 - [ ] Step 9 — Manifests + docs
 
@@ -133,3 +133,16 @@ Deviation from the plan's letter: `recoverMiddleware` keeps `s.log`. It sits
 *outside* the tracing layer, so its request ctx never has the enriched
 logger — switching it to `FromContext` would silently drop the `"discovery"`
 name and gain nothing.
+
+## Step 7 — GC + health
+
+`gc.sweep` runs in a root span with `gc.providers` / `gc.deleted` counters
+(a failed orphan delete no longer counts as deleted — the loop grew an
+explicit `continue`). The health engine got the deferred `--trace-health-probes`
+flag and `TraceProbes` field; the probe call moved into `runProbe`, which
+wraps it in a `health.probe` client span only when enabled, ending before
+`record` (which stays ctx-free by design). Probe transports remain
+uninstrumented so no traceparent can leak through a proxy to external
+targets. Probe→reconcile span links stay out of scope (GenericEvent carries
+no ctx; the workqueue coalesces events) — recorded in the architecture
+Decisions in Step 9.