add-observabilitylisted

# Add observability ## When to use - A feature adds a new success or failure outcome an operator needs to see. - A change adds an external call (HTTP, queue, DB) that can be slow or fail. - A branch or decision point exists where "why did it do that?" will be asked in production. - A path is currently a black box: it either works or it does not, with nothing in between to diagnose. Instrument the decision points and boundaries, not every line. Noise is as bad as silence: a log on every loop iteration drowns the one line that matters. ## Procedure 1. **Structured logging at decision points.** At each branch that changes the outcome, log one structured event (key-value fields, not an interpolated sentence) with enough context to reconstruct the decision: the inputs that mattered, the branch taken, the result. Use the repo's existing logger and field conventions. Never log secrets, tokens, or full request bodies. 2. **One metric per new outcome.** For each new outcome the code can produce, emit a counter (for example `widget_export_total{result="ok|error"}`). If the path has latency that matters, add a histogram or timer. One metric per outcome, named in the repo's existing metric convention, so a dashboard can show the rate and the error share. 3. **A trace span per new I/O.** Wrap each new external call in a span named for the operation (`db.widgets.query`, `http.acme-org.enrich`). Record the status and, on failure, the error class as a s