vendor: pin llama.cpp to f002015a4, so a restored KV page keeps its adapters (fork #54)

[joelteply]

What

This pins core/vendor/llama.cpp to f002015a4, moving the gitlink and LLAMA_CPP_PIN together. It is one commit over af1a3c933: fork CambrianTech/llama.cpp#54, which BigMama and Fable approved and which merged.

• SLOT_SAVE writes a .lora sidecar with each loaded adapter's path, scale, file size and mtime. SLOT_RESTORE sets the slot's adapters from it and refuses one that is missing or foreign.
• A turn with genes after a restore now keeps the restored KV, instead of reading as an adapter change and clearing it (the 5090, card e5eaf9f4).
• An adapter-free task now runs the same adapter-change check that upstream skipped.

The core already drains .lora with its page (#4942, merged).

Expected after deploy (not a regression)

Pages saved before this have no sidecar, so each mind's first restore is refused once. That is one cold prefill, after which the page is dropped.

Measured

This can only be measured after deploy. The check: on the 5090, a gene turn that follows a restore logs no clearing cache for lora change for that slot, and its cache_n is above 0. Owner: Cormac, with BigMama pulling the log lines. Deadline: the first 5090 deploy carrying this pin. The receipt card stays open until it is posted with the build SHA and a timestamp.

Coordination

#4939 also moves this pin, for fork #52. Whichever lands second rebases onto fork master, which then carries both.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FRQWzgSfo79JtnwZywHKrE

[joelteply]

Approve (BigMama, as a comment: shared account). Claims verified: the gitlink and core/vendor/LLAMA_CPP_PIN both move af1a3c933 -> f002015a4; f002015a4 is fork #54 squashed onto af1a3c933 (one parent, ahead by 1, one file, tools/server/server-context.cpp); and the new .lora sidecar is already disk-safe on canary: #4942 put it in slots.rs PAGE_SIDECARS ([".ckpt", ".lora"]), so trims remove it with its page. After deploy I own the receipt (a gene turn after a restore logs no 'clearing cache for lora change', cache_n > 0). Ordering note: #4939 and #4946 also bump or need this pin; whichever lands second rebases onto the newer pin, never back to af1a3c933.