…() on status + snapshot (audit: list-sessions-decode-on-poll)

Two routes — /api/status and /api/dashboard/snapshot — computed
session_count via substrate.list_sessions().map(|s| s.len()).
list_sessions() returns Vec<serde_json::Value> with each row's
full rmp-encoded message history decoded, so calling .len() on
the vec required decoding every blob just to count rows.

The dashboard polls /api/dashboard/snapshot every 5s with
refetchIntervalInBackground=false, so every foreground operator
hits it continuously. At 100 sessions × 200 KB each, the daemon
burnt ~20 MB/s of needless decode + rmp alloc on the hot path —
for what is morphologically a SELECT COUNT(*).

MemorySubstrate::count_sessions() (indexed SELECT COUNT(*)) already
exists in librefang-memory/src/substrate.rs:391; both call sites
now use it.

Delete the audit doc + INDEX update per the #5265 convention:
narrative 119→118, Critical 7→6, Total 120→119, drop the bullet
under Critical, and drop the list-sessions-decode-on-poll leg
from Pass 1 priority #4 (paired with audit-export-401; the other
leg is addressed by a separate PR so this PR only removes its own
half).

Two #[tokio::test] cases against TestServer that seed N sessions via
the memory substrate and assert the wire field reflects N — catches
the .unwrap_or(0) silent-pin regression class that the dashboard's
existing smoke test (only checks status='running') would miss.
Required by CLAUDE.md route-test policy and the audit doc.

Also: clarify the comment + CHANGELOG figure to '~20 MB per poll
(≈ 4 MB/s)' — the original ~20 MB/s number was off by the 5 s poll
period.

…ns-count

… [skip ci]

…ns-count

# Conflicts:
#	openapi.json
#	xtask/baselines/openapi.sha256

… [skip ci]