#52 nvme kv cache

Description

An nvme kv cache avoids constant prefills across multiple sessions (#47) so I'm taking a stab at it, testing it right now.  Once the tests on the live server come through I'll detail those tests. 

<details>
Whole-session snapshots (attention KV in every format + idx_pooled/idx_block_pos/ idx_dead/idx_tail + GDN/PLE running state + MTP drafter host KV) keyed by the exact token prefix, stored under --kv-nvme DIR:

- automatic synchronous cascade on DONE (idempotent; one growing file per conversation via strict-prefix supersede), fsync'd
- automatic promote on prefix match in the serve resume path - no client calls (a failed promote falls back to the clean session_zero path, never a mixed state)
- LRU byte cap (--kv-nvme-max GB); corrupt/foreign store files are refused, never converted, and can no longer crash the server
- atomic restore: the whole snapshot is validated before anything is applied
- STRATA_STATE_HASH refactored into state_hash_line() and shared with a new post-restore oracle (STRATA_NVME_HASH); verify.cpp: add <cmath> for Linux

Oracles: tools/nvme_p0_test.sh (bit-exact restore + negative control), tools/nvme_steps123_test.sh (cascade/supersede, promote-after-restart: 13 fresh tokens read in ~350 ms after a restart vs a full re-prefill; LRU cap evicts). Known engine property (documented): decode is run-to-run nondeterministic on v0.1.13 (pre-existing, reproduced with the old binary), so continuation token equality is informational; restore-exactness is the hard gate.

Design: docs/nvme-kv-cache-design.md; review: docs/nvme-kv-cache-critique.md (glm-5.3, design) and docs/nvme-kv-impl-review.md (glm-5.3, implementation, P1s addressed).
</details>

*edit* so for example, this is a round robin 110k needle-in-the-haystack example 
<img width="915" height="401" alt="image" src="https://github.com/user-attachments/assets/e0759f33-0ad7-4b9c-98a2-44012b73c57a" />
where we see delicious ttft bc of reuse, across three different long prompts.