fix: pre-built llama.cpp install fails with "Found 0 of 2" on first-run setup

[mmogr]

Fixes #319

What was broken

When a user ran make setup (without building llama.cpp from source) and then launched the GUI, the first-run setup wizard would download the pre-built archive but immediately fail with:

Installation failed
internal error: Failed to install llama.cpp: Failed to extract all required binaries. Found 0 of 2

Three bugs in crates/gglib-runtime/src/llama/download/mod.rs caused this cascade.

---

Commits

1. fix(download): replace stale build/bin/ filter with component-count guard

The extraction loop for .tar.gz archives filtered entries with:

if !entry_name.contains("build/bin/") { continue; }

This path never existed in llama.cpp release archives. The actual structure is:

llama-b<tag>/llama-server
llama-b<tag>/llama-cli
llama-b<tag>/libggml-metal.0.dylib

Every entry was rejected → extracted_binaries stayed 0 → the error fired.

Fix: replaced with a path-components length check — skip entries that are not exactly one level deep inside the archive's top-level directory. Resilient to future tag name changes.

2. fix(download): extract pre-built binaries into .llama/bin/ to match expected paths

All three download_prebuilt_binaries* functions used:

let bin_dir = gglib_dir.join("bin");

But llama_server_path() / llama_cli_path() (in gglib-core) expect binaries at resource_root()/.llama/bin/. The binaries would have landed in the wrong directory and the post-install verification step would have failed:

"Installation verification failed: binaries not found after extraction"

Fix: changed to gglib_dir.join(".llama").join("bin") in all three functions.

3. fix(download): write llama-config.json into .llama/ to match llama_config_path()

save_prebuilt_config wrote the config to data_root()/llama-config.json but llama_config_path() expects it at resource_root()/.llama/llama-config.json.

Fix: changed the write path accordingly.

4. test(download): add unit test for modern llama.cpp tar.gz archive layout

Added a unit test that constructs a synthetic tar.gz archive matching the actual llama-b<tag>/<filename> release layout, calls extract_binaries_tar_gz, and asserts both required binaries and a shared library are properly extracted. This test would have caught the regression in commit 1.

---

Testing

cargo test --package gglib-runtime --features prebuilt

New test: llama::download::tests::test_extract_binaries_tar_gz_modern_layout ✓

[mmogr]

Round 2 fix pushed (commits b428eca, 9e2473a)

After the round-1 fixes resolved the Found 0 of 2 error, testing revealed a second crash:

Installation failed
internal error: Failed to install llama.cpp: No such file or directory (os error 2)

Root cause: Modern macOS llama.cpp release archives contain versioned dylib symlink entries (e.g. libggml.dylib → libggml-metal.0.dylib). After entry.unpack() creates the symlink in bin_dir, the #[cfg(unix)] chmod block called fs::metadata(&dest_path)? — which follows symlinks (stat, not lstat). If the symlink target hadn't been extracted yet, this returned ENOENT with no context, propagating all the way up as the bare error shown above.

Fix:

• Both extract_binaries_tar_gz and extract_binaries_zip: replace fs::metadata with fs::symlink_metadata (lstat — doesn't follow symlinks), then skip set_permissions entirely for symlink entries (you can't chmod a symlink on macOS/Linux anyway)
• Add .with_context() to all previously bare fs:: error paths in the extraction and config-write code
• Unit test extended to include a dangling symlink entry that would have triggered the crash before the fix