#2923 [Bug] conversation cache skips snapshot restore under RAM pressure: parked -> next request does a full 310-372K re-prefill (4/4), same sequence recovers normally when RAM is plentiful

Descrição

> All numbers below are from a single production log (`strata-iq3_s.log`, v0.1.44) over 2026-10-17, quoted verbatim.

Related: #2228 (coarse-checkpoint fallback for a fast client — same family, mild form: 6.8K-47K re-reads; this report is the heavy form with a RAM-pressure variable), #2316 (slow replay on cache hit), #2409/#2408 (restore-path OOMs).

One more observation: the leftover `reused` value is always exactly **16384** — the default `--prompt-cache` grid step — which matches #2228's 32,768-grid finding (their rig sets `--prefill auto:32768`). So under RAM pressure the engine seems to fall back to the first grid checkpoint (or skip restore entirely) and re-prefill everything since.

## Environment

- Strata v0.1.44, win32, 79.9 GB physical RAM, RTX 3090 24 GB
- Single client (one ZCode window), single long session, port 8080
- Flags: `--max-context 524288 --kv int8 --conversation-cache-mib 12288 --conversation-cache-slots 3 --conversation-cache-min-free-mib 2048`
- Session grew 321K → 388K tokens over ~2.5 hours of continuous agent work

## Symptom

4 times tonight, the first request after a successful `parked` did **not** recover the snapshot and instead did a **full re-prefill** (310K–372K tokens read, 233–285 s at ~1300 tok/s):

```
prompt 325540 tokens = 325109 reused + 431 read ... 3129 generated
conversation cache: parked 328669 tokens in 2278.5 ms; parked=2 bytes=11511460824 evictions=42
prompt 330755 tokens = 16384 reused + 314371 read in 233714 ms (1345.1 tok/s), 195 generated   <-- full re-read
conversation cache: skip parking (physical RAM admission; need 5613 MiB plus 2048 MiB floor, 5840 MiB available)
conversation cache: restored 325535 tokens (checkpoint) in 1227.0 ms
prompt 328860 tokens = 325535 reused + 3325 read in 6281 ms   <-- normal
```

The re-read request is just snapshot + ~2K new tokens (`330755 = 328669 + 2086`), so the recovery path should have hit. Same pattern at 335593 (cancelled after 233 s re-read), 336411, and 388629:

```
conversation cache: parked 386540 tokens in 1338.4 ms; parked=1 bytes=6735893912 evictions=48
prompt 388629 tokens = 16384 reused + 372245 read in 284937 ms (1306.4 tok/s)   <-- full re-read
conversation cache: skip parking (snapshot 6457 MiB exceeds available budget)
```

All 4 re-reads follow a `parked` within one log line. Zero re-reads happened in any other situation tonight.

## Control group (same day, ~8 hours earlier, RAM not yet tight)

Same sequence — parked, then next request — recovers and hits normally even at 449K tokens:

```
conversation cache: parked 449168 tokens in 2936.3 ms; parked=1 bytes=7692905940 evictions=4
prompt 448985 tokens = 442368 reused + 6617 read in 8979 ms (737.0 tok/s)   <-- recovered, normal
```

Restore latency comparison, same magnitude snapshots:

| RAM state | restore | tokens |
|---|---|---|
| plenty | 134.9 ms | 69583 |
| plenty | 477.6 ms | 285205 |
| tight | 20481.9 ms | 332285 |
| tight | 5187.7 ms | 386625 |

So under RAM pressure snapshots page out, and the engine appears to skip the recovery path entirely and re-prefill from scratch — 4-5 minutes instead of seconds.

## Secondary observation

`--conversation-cache-mib 12288` cannot hold two snapshots of a 380K-token session (7.0–7.7 GB each):

```
conversation cache: parked 386540 tokens ... bytes=6735893912
conversation cache: skip parking (snapshot 6457 MiB exceeds available budget)
```

## Question

Is skipping recovery under RAM pressure intentional (avoid page-in death spiral), or should the engine prefer restoring the snapshot? Even with a slow page-in (~5-20 s), restoring beats a 285 s re-prefill by an order of magnitude. Either way, a log line explaining *why* recovery was not attempted would help diagnosis.

Also: is 12 GB a reasonable default budget for `--conversation-cache-mib` on a 79.9 GB machine running ~400K-token sessions, given one snapshot alone is 7+ GB?