Expose recording health counters (writer stats) to operators

The recording writer keeps operational counters internally — attempted / written / dropped records, loss markers, self-disable state, and panic counts — but none of it is exposed through logs or a metrics endpoint.

During validation the live drop count could only be derived after the fact from the tape contents (line count vs loss markers), and the self-disable / panic-count state was not observable at all while running.

## Ask

Expose the writer stats snapshot to operators, so a recording fleet can be monitored:

- A periodic structured log line and/or a metrics endpoint carrying attempted / written / dropped counts.
- The self-disable transition (the writer disabling itself after repeated sink errors) surfaced as an explicit signal, not just an internal flag.
- Drop count exposed live, so sink saturation is visible during an incident rather than reconstructed afterward.

This is the observability prerequisite for operating recording under real traffic.

Start by locating the recording writer's internal stats snapshot and the existing structured logging or metrics endpoint entry points. Trace attempted, written, dropped, loss-marker, self-disable, and panic-count state through runtime operation. Done means operators can observe the counters live and receive an explicit self-disable signal during sink failures.

Written by the indexing model from the issue text.