[Observability] Decide whether the addon is tracing-only or complete the observability surface

[cssbruno]

Problem

The current addons/observability surface is primarily tracing. That is a valid first slice, but the name and status copy imply a broader observability story than the runtime currently provides.

Verified in this checkout:

• docs/reference/observability.md describes generated GOWDK Trace wiring, a local trace viewer, traceparent, and optional OTLP export.
• runtime/app.Metrics currently records dependency-free counters for broad dispatch paths, but not latency, active requests, route-template/endpoint-ID metrics, error rates, exporter failures, or trace collector health.
• docs/engineering/operations.md still frames route counts, request counters, traces, alerts, and dashboards as partial/future operations concerns.

Acceptance criteria

Choose and document one direction:

1. Rename/reframe the current addon/docs as Tracing until metrics/log correlation are real; or
2. Keep Observability and add the missing minimal surface.

If keeping Observability, add or explicitly track:

• log/slog integration that injects trace ID and span ID into generated/app-owned logs.
• Dependency-free low-cardinality route metrics: request count, latency, active requests, errors, dropped spans, and exporter failures.
• Stable attributes keyed by route templates and endpoint IDs, not raw URLs.
• A health snapshot for collector/sink queue depth, export latency, dropped spans, and sampling configuration.
• Docs that separate app-owned telemetry storage/retention/hosted analysis from GOWDK-owned local primitives.