fix: resolve shared-repo GGUF variants orphaned by refs/main advance

[ianbmacdonald]

Problem

refs/main in a Hugging Face repo cache is a single sticky pointer (advanced only on a successful pull). When two models share one HF repo with different quants, pulling or updating one variant advances refs/main to a snapshot that contains only that variant — the sibling variant's file stays behind in the previous snapshot.

The llamacpp main-GGUF resolver (ModelManager::resolve_model_path) collected candidate GGUFs from the refs/main snapshot only, with a whole-cache fallback that fired solely when that snapshot had zero GGUFs. So after the next models-cache build (e.g. a lemond restart), the sibling variant — present, but not under refs/main — was reported as not downloaded even though its file is still cached. Fixes #2300.

Fix

Factor the variant-matching cases into a resolve_gguf_variant lambda. Try the active refs/main snapshot first; only if that misses, broaden the search to every snapshot in the repo cache before declaring the variant missing.

• Active snapshot first preserves the CHECKPOINT:VARIANT contract — a different quant is never substituted while the exact one exists under refs/main.
• Blobs are content-addressed and shared across snapshots, so reading an older snapshot's copy is safe.
• The whole-cache walk is lazy (only runs on a miss), so the hot path is unchanged.
• The auxiliary-checkpoint resolver already had this all-snapshots fallback; this brings the main GGUF path in line.

The C++ diff is mostly reindentation of the existing cases into the lambda — each case's matching behaviour is unchanged.

Test

test_034 (server_endpoints.py): pulls two quants sharing a repo, moves one into a fresh snapshot and advances refs/main, forces a models-cache rebuild (via an unrelated throwaway pull — re-pulling a shared-repo model would query HF and repair refs/main, masking the bug), then asserts both variants stay resolvable. Fails on main, passes with this change.

Validation

Exercised on real hardware:

• lemonade: 10.8.0 (imac-built dev .deb carrying this branch; not a release)
• OS / kernel: Ubuntu 26.04 LTS · 7.0.0-22-generic · glibc 2.43 · amd64
• GPU: AMD Radeon RX 7900 XT (Navi 31 [1002:744c], gfx1100, RDNA3, 24 GB)
• Backend: none — test_034 and test_030–test_033 exercise GGUF cache/path resolution and the pull-variants API; no model is loaded, so no inference backend or ROCm runtime is invoked.

test_034 fails on an unpatched build and passes with this change; the existing test_030–test_033 pull-variant tests remain green.

[ianbmacdonald]

CI is green except for Build Lemonade macOS .dmg (with Tauri App), which fails in its whisper Metal inference tests (unsigned path) step (test_001_transcription_basic). That's unrelated to this change (a GGUF cache-path resolver fix — no whisper/Metal/inference touched), and the same job is currently failing on main, so it looks like a pre-existing macOS-Metal issue rather than anything introduced here. The macOS C++ build (Build Embeddable Lemonade (macOS)) and all other build/test jobs pass.