Brief P9: slots are pinned but not reserved; cache loss is a normal event

Approved 2026-09-17. Evidence is in docs/decisions.md.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/design.md

@@ -96,8 +96,14 @@ ordinary outbound networking can reach the whole tailnet and the internet as the
 3. **No in-place pruning.** Tool results are size-capped when first appended, never trimmed later.
 4. **Compaction is an epoch change.** It happens only when the session is idle, writes a summary,
    and starts a new epoch whose prefix is the baseline plus the summary. The old log is kept.
-5. **Pinned slots.** Main session, subagents, and scheduled runs each use their own server slot so
-   they do not evict each other's cache. Verify the pinning mechanism on the deployed build.
+5. **Pinned slots, not reserved.** Every request carries `id_slot`, and a session always uses the
+   same slot: moving it costs a full re-read. Slot assignment is configuration. With the two slots
+   deployed today, main sessions (one per Mattermost thread) share one slot, and subagents and
+   scheduled runs share the other. The server is shared, so another client can take a harness
+   slot and the router can unload Ornith. An evicted session is normally restored from the
+   server's host-RAM prompt cache when it returns on its slot; an unloaded model is not. Cache
+   loss is therefore an expected event: `loopd` detects it (`cache_n` far below the previous
+   request's total), records it in the session log and carries on. It is never an error.
 6. **Progressive disclosure.** The `tools` array is fixed for the whole epoch. The template renders
    it at the top of the prompt, so any change re-reads everything. Only a small core tool set has
    schemas in it. Everything else is found through `find_tool`, which returns schemas as an