setup: preserve warm genie-ai-runtime model cache

[Crystora]

Summary

Fixes #69.

This keeps Qwen3 model weights warm across genie-ai-runtime.service restarts instead of forcing every start down the cold-load path.

Changes:

• Remove the drop_caches ExecStartPre from genie-ai-runtime.service.
• Add /opt/geniepod/bin/genie-model-cache-status.sh to report Linux page-cache residency for the configured GGUF using mincore.
• Deploy the helper through make deploy-setup.
• Print the helper in the Jetson setup footer.
• Add static tests covering the service behavior and helper deployment.

Roadmap check

Checked GeniePod/genie-ai-runtime ROADMAP before finalizing this. The runtime already has per-run model-load timing plus scripts/bench_load.sh, and the v1.0 notes call out:

• cold model load: ~30s, NVMe-bound
• warm model load: ~1.3s, page-cache hit

So this PR keeps the fix in GenieClaw deployment: do not evict the model from page cache immediately before starting the default runtime.

Validation

• bash -n deploy/scripts/genie-model-cache-status.sh deploy/setup-jetson.sh deploy/scripts/start_all.sh deploy/scripts/stop_all.sh
• bash deploy/scripts/genie-model-cache-status.sh deploy/config/geniepod.toml
• make -n deploy-setup JETSON_HOST=192.168.55.1 JETSON_USER=aihpc
• cargo test -p genie-core --test tool_dispatch_test jetson_lifecycle_scripts_are_valid_shell
• cargo test -p genie-core --test tool_dispatch_test makefile_deploys_lifecycle_helpers
• cargo test -p genie-core --test tool_dispatch_test genie_ai_runtime_service_preserves_model_page_cache
• cargo test -p genie-core --test tool_dispatch_test model_cache_status_helper_reports_residency
• git diff --check

[Crystora]

Jetson acceptance for #69:

== before start ==
Model: /opt/geniepod/models/Qwen3-4B-Q4_K_M.gguf
Size: 2382 MB
Resident: 0 / 2382 MB (0.0%) cold
== after first start ==
Model: /opt/geniepod/models/Qwen3-4B-Q4_K_M.gguf
Size: 2382 MB
Resident: 2382 / 2382 MB (100.0%) warm
== after restart ==
Model: /opt/geniepod/models/Qwen3-4B-Q4_K_M.gguf
Size: 2382 MB
Resident: 2382 / 2382 MB (100.0%) warm

This confirms removing drop_caches from genie-ai-runtime.service preserves Qwen3 GGUF page-cache residency across service restart. CI is green.

[ai-hpc]

Clean, narrowly-scoped fix that does exactly what #69 asks for. The original ExecStartPre=/bin/sh -c 'sync && echo 3 > /proc/sys/vm/drop_caches' was over-eager: the comment justified it with "Jetson NvMap needs contiguous blocks", but the kernel's allocator compacts on demand and we don't need to pre-clear the cache to get a successful first load. Removing it makes restart-after-restart hit the warm path (Linux page cache holds the GGUF pages between runtime stops/starts since the file is still mmaped to a recent reader).

The genie-model-cache-status.sh helper is well-designed:

• Uses mincore(2) via Python ctypes — the right syscall for "is this page resident?". Returns per-page residency bits.
• mmap opens with ACCESS_COPY (MAP_PRIVATE) so the probe is read-only — won't dirty pages or trigger writes.
• Reads [core].llm_model_path from geniepod.toml with section-aware awk that mirrors PR #63's pattern, so it can't accidentally match an llm_model_path = line outside [core] (none exists today, but the discipline is correct).
• if [ "$(id -u)" -eq 0 ]; then AWK=(awk); else AWK=(sudo awk); fi — auto-sudos for the 0600-locked config so the helper works for non-root operators.
• 0-byte file is handled cleanly (prints 0 / 0 MB cold, exit 0 — no division by zero).
• del buf before mm.close() is the right ctypes-cleanup idiom; without it mmap.close() fails with "cannot close exported pointers exist".
• 95% / 1% thresholds for warm / cold are sensible; "partial" covers the in-between case during eviction pressure.

The four lock-in tests are smoke-tests rather than behavior tests, but they're exactly the right ones for this change — pin "no ExecStartPre= in the genie-ai-runtime service", pin "issue #69 referenced in the comment", pin "helper uses mincore + reports Resident:", pin "Makefile deploys the helper". A future PR that accidentally re-adds the drop-caches line or breaks the deploy path will fail CI loudly. The test that explicitly asserts the comment mentions "issue #69" is a nice touch — future archaeologists can trace the rationale back to the issue.

The end-to-end measurement on the operator's Jetson (linked in the PR comment / chat) is the proof: model cache residency is 0% → 100% on first start, then 100% across systemctl restart, then a subsequent jetson-llm interactive load reports Model loaded in 1161 ms (2051 MB/s) — the warm path, vs the ~30s cold path documented in the runtime ROADMAP. That's a ~25× restart speedup with zero downside on the typical 7.6 GB Orin Nano + Qwen3-4B Q4_K_M deployment.

One small note for a follow-up (not blocking): the new comment on the ExecStartPre line says what changed but the old "Jetson NvMap needs contiguous blocks" rationale lived for a reason. If memory-pressured deployments later report a cold-load regression due to fragmentation, a paragraph in the service file explaining "we used to drop caches; here's why we no longer think that's necessary" would help the next person tempted to add it back. Not blocking — the linked issue carries enough context.

All 7 checks green on a712973 including the new cargo clippy + test (--no-default-features) job from #62. Going in.

[ai-hpc]

Merged at daf9bfd7ffddfa264539687df7999d8afdabdc8c.
Thanks to @bittoby!

[Crystora]

Additional service-path validation:

• genie-model-cache-status.sh reports Qwen3 fully warm: 2382 / 2382 MB (100.0%) warm.
• genie-ai-runtime.service is active and /health returns status: ok for Qwen3 4B Instruct Awq.
• OpenAI-compatible chat endpoint works:

{"content":"Hello from GeniePod!","model":"Qwen3 4B Instruct Awq","usage":{"completion_tokens":7,"prompt_tokens":23,"total_tokens":30}}

This confirms the normal service path preserves warm model weights and serves chat completions. Remaining board note: genie-core is still offline/auto-restarting and should be diagnosed separately from #69.