Trace discovery API requests and enrich request logs

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

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

@@ -7,7 +7,7 @@ Plan: `docs/plans/2026-08-24-1025-otel-tracing.md`
 - [x] Step 3 — `provider.WithTracing` decorator
 - [x] Step 4 — `cmd/main.go` wiring
 - [x] Step 5 — Reconciler spans
-- [ ] Step 6 — Discovery server
+- [x] Step 6 — Discovery server
 - [ ] Step 7 — GC + health
 - [ ] Step 8 — GCP wire-log enrichment
 - [ ] Step 9 — Manifests + docs
@@ -118,3 +118,18 @@ span's content — a real PATCH shows up as its k8s HTTP child). Tests that
 call `r.Reconcile` directly bypass the wrapper; with no global tracer set
 they see no-op spans, so the existing fake-client and envtest suites run
 unchanged.
+
+## Step 6 — Discovery server
+
+Middleware chain is now recover → tracing (server span + request logger) →
+request-log → body cap → auth; the request-log middleware and the three
+handler error sites log via `logf.FromContext(r.Context())` — which is
+`s.log` enriched with the request's traceID/spanID by the tracing
+middleware, not a different logger (logr sinks can't read ctx at log time,
+so per-request values must ride on the logger instance in the ctx; user
+asked, answered in-session).
+
+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.