feat(agent): report hook liveness and aggregated hook errors

[graywolf336]

Problem

atomic agent status answered "are the hooks installed?" and stopped. It could not answer "are they still working?" — and that's the expensive question. The shell guard in atomic-agent::hooks ends in || true, so a hook that dies is indistinguishable from one that was never installed, and a failing dispatch drops the turn silently.

In this repository, .atomic/hook-errors.log held 1,784 lines over 6 days across 21 sessions — 546 of them the same failure (Provenance turn N is not running) — and no command would ever read it.

Changes

• Liveness — every hook dispatch records to .atomic/hook-health.json: per-agent, per-verb last_fired + outcome. last_ok is preserved across a later failure, so "worked then broke" is distinguishable from "never worked". Written on the dispatch path and the parse-failure path.
• Errors — a bounded tail read of hook-errors.log, aggregated by a signature that collapses session ids and turn numbers, turning 546 near-identical lines into one row. Continuation lines fold into their entry (the plugin appends messages unescaped; dropping the tail was losing the actual error).
• Surface — both in atomic agent status (human + --json), plus a silent_agents list naming hooks that are installed but have never recorded. Empty when no health file exists, so a freshly-upgraded repo isn't accused.

The two signals print together because either alone misleads: a clean error log says nothing about whether the recorder is running, and a live recorder says nothing about what it failed to do earlier.

Verification

• cargo test -p atomic-cli — 1952 passed, 0 failed (20 new)
• clippy clean, fmt --check clean
• Harness 25, 33, 34 pass. 20_sandbox fails identically on dev — pre-existing (draft view 'agent-3' created), verified by stashing and re-running.
• End-to-end on a scratch repo: real hook fire → health written; malformed payload → outcome: error recorded with last_ok retained.
• Against the real 1,784-line log: 546 dropped turns collapse to one class.

Self-review findings

Both surfaced only when the feature was run against real input, not by unit tests — the parser takes strings in memory, so the file-reading path and the early-return path were unexercised. Both were introduced in this branch, are not present on dev, and both now carry regression tests:

1. A whole-file read dropped its first entry. The tail-trim that discards a partial line after a seek also ran when start == 0 and no seek had happened. Because the log is append-only, that silently dropped the oldest error — and a repo with exactly one error reported zero. The unit tests fed the parser strings, so only the scratch-repo run caught it: a 5-entry log parsed as 4.
2. Parse failures never recorded. They return before the dispatch block, so the health write was unreachable — the exact case where recording matters most, since a malformed payload is what an agent upgrade produces.