App-wide health / audit-log + anomaly-watch system (model-event-sourced)

## Operator idea (2026-07-04) Motivated by feedback #77 / brief #171 (brief_dispatch & brief_claim responses overflowing the MCP token cap and spilling to a file). Rather than only catching such anomalies when an agent happens to report them, build a first-class way to **record + surface anomalous / "keep an eye out" events** — and possibly a broader audit log. ## Two scopes to decide between (or A now → B later) **A. Targeted health / anomaly-watch log + alerts.** A `health_events` / `anomalies` store that specific code paths write to when something noteworthy happens — e.g. "brief_dispatch response hit the MCP max size and spilled", migration failed mid-run, summarizer cURL-28 timeout, oversized MCP payload, failed_jobs spike, daemon MIA. Surfaced in a `/health` view (extend the existing `recall_health` tool) with optional alerting. Lightweight, opt-in per call-site. **B. Comprehensive audit log of ALL actions.** A Laravel-side, model-event-sourced audit trail (created/updated/deleted across models) via an Eloquent observer / global model events, ingested/processed via Horizon, queryable + surfaced in UI. Heavier; captures everything, not just anomalies. Needs sampling/retention thinking (high volume). ## What exists today (build the gap, not a dup) - `recall_health` — compact warnings about flower's own ingest/MCP/hook health (a snapshot, not an event log). - `brief_events` — append-only trace, but scoped **per brief** only. - `feedback` store — anomalies reported **manually / by agents** (e.g. #77), not auto-detected. - daemon roster `meta.audit`, Solo process history — partial + siloed. - No app-wide anomaly recorder, no model-event audit log, no alerting layer. ## Open decisions (refinement / operator) 1. Scope A vs B vs A-first-then-B. 2. Alerting: passive `/health` surfacing vs. active push (operator inbox note / daemon signal) on a severity threshold. 3. For A: seed set of call-sites to instrument — start with the MCP-response-oversize / dispatch-spill case that motivated this (the harness already detects & spills oversized tool results; a hook there could emit a health_event). 4. Retention / volume (B could be high-volume → sampling / TTL). ## Provenance Operator note 2026-07-04, chained off feedback #77 / brief #171. Sibling to #171: #171 fixes the immediate overflow; this brief is the systemic "record + watch for anomalies" idea. Status: idea — needs an operator scope decision + refinement before dispatch. Do NOT auto-dispatch.