telemetry-batterylisted

# Telemetry battery For issue #199: validate the telemetry system itself, on a cadence, separately from optimizing LDL. Invoke roughly weekly, after real LDL/consumer activity has accumulated — never per issue, per merged PR, or per methodology tweak. If the last recorded row in `docs/telemetry-battery-log.md` is under a week old and no unusual volume of work has happened since, say so and stop rather than running again. ## Step 1 — telemetry coverage, before any optimization claim Run: ``` node tools/telemetry/coverage.mjs --all --exclude-ids-file docs/telemetry-battery-log.sessions.json [--exclude-session <this session's id, if known>] --json ``` (On the very first run, `docs/telemetry-battery-log.sessions.json` does not exist yet — `--exclude-ids-file` against a missing file is the same as excluding nothing.) Do **not** pass `--record-ids` on this invocation — recording happens later, in Step 4, only once the result is durably written. `--all` scans every session not already excluded, regardless of mtime; `docs/telemetry-battery-log.sessions.json` (durable, git-tracked, growing only via `--record-ids`) is what actually guarantees two runs never double-count the same session. Neither `--since` nor `--sample` (mtime-based alternatives `coverage.mjs` also supports) is a disjointness guarantee: a resumed or still-running session's file keeps getting touched, so its mtime can cross a cutoff again even though it was already counted, and an advancing cutoff can p