#1920 Prompt-cache checkpoint pool: two alternating long conversations evict each other and both re-read from token 0 every turn (no batch-groups)

Descripción

### Engine version

0.1.42 (compiled from main for sm_70, CUDA 12.0, Linux)

### Hardware

1x Tesla V100-SXM2-32GB, 23 GB system RAM, i5-8400 (6 cores)
Model: Qwen3.8-Flash-Next IQ2_XS, low-RAM resident mode, `--max-context 262144 --kv q4_0`

### What happened

Two Hermes agent conversations share one Strata server. Both grew to ~170K tokens.
While both were active, **every turn of both conversations re-read the whole prompt**
(~145 s per turn at ~1190 tok/s), even though the engine kept writing checkpoints:

```
strata serve: prompt 175141 tokens = 172470 reused + 2671 read in 3770 ms (708.5 tok/s), ... 6 checkpoints
strata serve: prompt 173168 tokens = 0 reused + 173168 read in 146196 ms (1184.5 tok/s), ... 12 checkpoints
strata serve: prompt 681 tokens = 0 reused + 681 read in 1327 ms (513.1 tok/s), ... 1 checkpoints
strata serve: prompt 176636 tokens = 0 reused + 176636 read in 148586 ms (1188.8 tok/s), ... 12 checkpoints
```

The alternating short request is the third conversation (a tool-call turn, ~600 tokens).
No `skip parking` lines in the log (conversation-cache parking never engaged; this is
the `--prompt-cache` checkpoint pool, not the parked-session tier).

### Diagnosis

With the default `--prompt-cache-every 16384`, a ~170K conversation wants ~11-12
checkpoints of its own. Two such conversations need ~24 slots but the pool is 6 by
default (I raised it to 12, then 16): each turn rewrites its own 12 checkpoints and
evicts the other conversation's, so neither finds a matching prefix on its next turn
and both re-read from token 0. The `N checkpoints` counter stays healthy — it counts
writes, not reuse — which is what makes this easy to miss.

Single-conversation use is fine (reuse 99.9%, 1-2 s per turn on ~890-token deltas);
it only collapses when two long conversations alternate. This looks like the same
family as #1604 (checkpoint pool starvation with more than one conversation) but
without `--batch-groups` involved — plain serial serving, one slot.

### Workaround applied

`--prompt-cache 16 --prompt-cache-every 32768` (a ~170K conversation then wants ~6
checkpoints, so 16 slots hold both). I have not yet measured the steady state after
the change; will report back.

### Suggestion

When the pool is too small to hold the checkpoints of the conversations that were
active in the last N turns, consider a cheaper retention policy: keep the FIRST
checkpoint of each conversation (the system-prompt root, `--prompt-cache-root`
already exists) even when the tail checkpoints of that conversation are evicted, so
an alternating long conversation at least reuses the root instead of re-reading from
token 0. A one-line log when a checkpoint write evicts another conversation's newest
checkpoint would also make this diagnosable from the log alone.

Thanks for the engine — the resident low-RAM mode runs IQ2_XS at 68-88 tok/s on this
V100 box, which is genuinely remarkable for a 23 GB RAM machine.