rust-observabilitylisted

# Rust Observability **Operator evidence.** Start with the operational question and choose the smallest signal that answers it; every emitted field is either evidence or avoidable cost. Honor supplied requirements and preserve settled choices outside the requested change; resolve only what the task leaves open. Logs are tracing events with structured fields and a stable snake_case event name an operator can search, never formatted sentences. Correlation is already carried: every record inside a request has the request id, trace id, and span id from the span the hardened chain opened, so do not thread identifiers by hand or log them twice. The process installs exactly one subscriber in the telemetry crate; library crates never install one and never configure levels. Metrics go through the metrics facade with a describe call beside the first use and snake_case names ending in total for counters. Labels are a cardinality budget: use route templates with an explicit unmatched label, finite outcomes, and problem codes; never a raw path, a user id, a peer address, or an error message. HTTP server, process, and Tokio runtime metrics already exist; add an instrument only for a question they cannot answer, and keep the diagnostics listener serving the metrics route alone. Spans for HTTP come from the tracing layer in the chain; inner operations use the instrument attribute and record identifiers and outcomes as fields rather than payloads. Every field is a disclosure surface: no s