ms: storage health + query latency + maintenance ops in Settings

[Ehco1996]

Summary

Adds a self-contained, dependency-free observability layer over the local SQLite metrics store, embedded directly in ehco's own admin SPA. No external Prometheus / OTel collector — ehco does it all itself.

Three new cards in Settings:

• Storage — file size, pages, freelist (with VACUUM hint when fragmentation > 30%), row counts, last rule write age. Calls out an empty rule_metrics table inline so a broken sync pipeline is visible.
• Query Latency — count / avg / max / last per op (add_node, add_rule, query_node, query_rule, cleanup, vacuum, truncate), since process start. Reset button.
• Maintenance — Clean older-than-N-days · VACUUM · Truncate (literal-match confirm).

Design notes

• No third-party libs. ~80 LoC for stats, ~10 LoC PRAGMA per metric. The track(*opStats) func() helper is the only instrumentation shape — every public ms method ends with one defer track(&ms.stats.X)() line.
• Row count is atomic.Int64-cached. Avoids SELECT COUNT(*) on every Settings refresh; reconciled by recountRows() after Vacuum/Truncate and at startup. INSERT OR REPLACE can briefly overcount on duplicate PKs — bounded, doc'd, self-healing.
• Truncate requires confirm == "yes I am sure" exactly (string, not bool — a defaulted JSON field can never wipe data).
• Vacuum is synchronous. Current ~2.5MB db: <100ms. Past ~1GB: lock window stretches into seconds; SPA confirm copy mentions this.
• All maintenance ops auth-gated by the existing /api/v1 echo group middleware — confirm strings are a second line of defence, not the first.

API surface

GET  /api/v1/db/health
POST /api/v1/db/cleanup       {older_than_days: int}
POST /api/v1/db/vacuum
POST /api/v1/db/truncate      {confirm: "yes I am sure"}
POST /api/v1/db/reset_stats

When the underlying store is disabled (no upstream sync URL), every endpoint returns 503 via cmgr.ErrMetricsDisabled.

Test plan

• go test -race ./internal/cmgr/ms/... — round-trip, cleanup, truncate strictness, reset (all PASS)
• make lint clean
• make test full suite green
• make ui builds (Vite OK, +~3KB gzipped)
• Smoke on a live node: hit each endpoint, verify Settings cards render, confirm rule_metrics=0 warning shows on the boxes that surfaced in the original investigation
• Watch latency card under load — sanity-check that add_node p~max stays sub-ms on real traffic

Why

Direct outcome of investigating PR #443's "SQLite 撑不住" claim. Probing a real node showed: 2.5MB db, all queries <1ms, but rule_metrics empty (separate sync-pipeline bug). Decision: stay on SQLite long-term; build observability so future "撑不住" judgements are data-driven, and surface the empty-table case loudly so the underlying bug doesn't hide.

🤖 Generated with Claude Code