DBSIZE under-reports logical keys under disk-offload (counts resident only)

[pilotspacex-byte]

Found during the 2026-07-16 G2 re-run (docs/perf/2026-07-16-g2-10x-ram-rerun.md, main @ 4dcfd53):

Observed: 4 shards, 256MB cap, disk-offload enabled, ~164K distinct logical keys written (2.6GB of 10KB values). Cold-index recovery logs show ~179K cold entries across shards, and all sampled cold keys GET correctly — but DBSIZE reports 24,275 (the resident set only), both during live spill and after restart.

Expected (Redis parity): DBSIZE counts logical keys — a spilled-but-readable key is still a key. Under-reporting by ~86% breaks operator capacity math and any tooling that trusts DBSIZE.

Notes:

• Pre-existing semantics gap: spilled keys leave the hot DashTable (ColdIndex tracks them); nothing in the v0.8 batch introduced this — the batch only made it visible (truthful used_memory + stub-only recovery investigation).
• Likely fix direction: DBSIZE = hot table count + ColdIndex live count per shard (minus overlap for hot keys with cold shadows), or maintain a per-shard logical-key counter updated at spill/promote/DEL/expire boundaries.
• Related invariants to keep: FLUSHALL/FLUSHDB cold-plane tombstones (PR fix(persistence): replayed DEL/FLUSH tombstone the cold plane; spills no longer suppress AOF recovery #257), cold-shadow overwrite clearing (PR fix(storage): truthful used_memory under disk-offload — RSS→logical ledger, stub-only recovery, replay demote (task #56) #349), SCAN semantics (does SCAN surface cold keys? worth checking in the same pass).

Severity: correctness/parity, non-blocking for v0.8 GA (documented in the G2 report + PRODUCTION-CONTRACT MEM-10X-01 row).