fix(serve): bound registry eager-preload to --max-loaded-models (#133)

[Pushkinist]

Summary

rmlx serve --registry <file> eagerly preloaded every model in the registry at startup, ignoring --max-loaded-models K. With a 13-model registry that is a ~5-minute boot that loads all 13 once, contradicting the documented load-on-demand / idle-unload model.

Root cause: the eager-preload loop in crates/rmlx-cli/src/commands/serve.rs iterated over all registry.list() entries calling ensure_loaded. AppState::ensure_loaded LRU-evicts once slots.len() >= max_loaded_models, so preloading N at cap K paid the full load cost for all N but kept only the last K resident — pure waste + transient memory pressure.

Fix

Bound the eager preload to at most max_loaded_models entries (min(cap, N)):

let cap = max_loaded_models.max(1);
let ids: Vec<String> = state.registry.list().iter().take(cap).map(...).collect();

This warms exactly the resident-set size and removes the N-load thrash. The rest stay lazy via the documented on-demand path. Best-effort semantics, spawn_blocking off-runtime execution, and per-model idle timers are unchanged. .max(1) keeps preload sane at cap 0 (a pre-existing pathological value, out of scope here).

Note: registry.list() iterates a BTreeMap sorted by id, so the preloaded set is the alphabetically-first cap ids — deterministic, not JSON array order. Comments + docs/CLI.md updated to say so.

Tests / proof

• e2e comments in runner.rs / manifest.toml updated to the new bounded behavior (comment-only; assert_model_lifecycle already exercises the cap=1 registry path).
• Real-model proof: 3-model registry (gemma4 26b/e2b/e4b) served with --max-loaded-models 1 → exactly one "eager preload starting/complete" pair at boot (was three). On-demand still works: chat to a non-preloaded model → 200 "Paris", serve log shows it loaded on first request and LRU-evicted the preloaded one.
• make ci green (fmt-check + clippy -D warnings + test + deny + audit).

Closes #133.

🤖 Generated with Claude Code