`llmfit update` fetches model lists successfully but caches 0 of 237 models

### Bug description

llmfit version: 1.1.6
OS: Linux (x86_64), Ubuntu 24.04
Install method: binary at ~/.local/bin/llmfit

Summary

llmfit update successfully fetches the trending/download-ranked model lists from HuggingFace (237 unique models total), but the subsequent per-model config.json processing step silently discards every single one. The cache file is written but ends up with an empty models array (34 bytes). This happens consistently across multiple runs, with a freshly-created HuggingFace token, and with --no-dashboard set.

Steps to reproduce

rm ~/.local/share/llmfit/hf_models_cache.json
llmfit update

Output

Fetching 100 trending models from HuggingFace...
Received 100 trending text-generation models
Received 25 trending image-text-to-text models
Received 25 trending any-to-any models
Received 25 trending text-to-speech models
Fetching 50 top-downloaded models...
Received 50 download-ranked text-generation models
Received 12 download-ranked image-text-to-text models
Received 12 download-ranked any-to-any models
Received 12 download-ranked text-to-speech models
Processing 237 unique models (fetching config.json for KV cache metadata)...
Saving 0 cached models (0 new)...

No new models found — cache is up to date.
Total cached: 0

What I've ruled out

Network/DNS/TLS reachability — confirmed working:
curl -sIL https://huggingface.co/Qwen/Qwen2.5-7B-Instruct/resolve/main/config.json | grep -i "^HTTP"
HTTP/2 307
HTTP/2 200
HuggingFace auth/token — tried both without a token and with a freshly-generated Read-scoped token (~/.huggingface/token). No change in behavior. A gated model (meta-llama/Llama-3.1-8B) does return 401 as expected, but this can't explain 237/237 failures since the vast majority of trending/top-downloaded models are not gated.
The --no-dashboard background server — strace -f -e trace=network during a normal update run showed a tight retry loop of connect() calls to 127.0.0.1:8787 returning ECONNREFUSED. Re-ran with --no-dashboard explicitly set: identical 0-cached result, so this loop is not the root cause (though it may be worth fixing separately as background noise).
Rust internal logging — RUST_LOG=debug llmfit update --no-dashboard produced byte-for-byte identical output to a normal run. No additional logging was emitted, so either llmfit doesn't use the standard Rust logging crate conventions, or update's fetch/cache step doesn't have any instrumented log statements.

My leading (unconfirmed) theory

Every config.json fetch requires following an HTTP redirect (307 → real resolve-cache URL → 200). If the internal HTTP client used specifically in the update bulk-fetch path is configured not to follow redirects (while other commands may use a different client/path), that would explain silently treating all 237 fetches as failures with no visible error.

However, this theory is not confirmed. A follow-up test complicates it:

llmfit search "2026"

returned 16 real HuggingFace models (all obscure experimental fine-tunes) with Size and Context fields populated, but every computed field (Status, Score, tok/s, Runtime, Mode, Mem %) blank/-. This is a different failure signature than "zero data at all" and may simply reflect that these specific models lack full metadata, rather than confirming or refuting the redirect theory.

Separately, llmfit info Qwen/Qwen2.5-7B-Instruct returns complete, correct data (including live-computed VRAM fit matching my actual hardware) — but I can't tell whether this is from a live fetch or a built-in seed dataset bundled with the binary, so I can't use it to confirm whether the bulk-update code path is genuinely broken versus just this one command.

Request

Since llmfit ships as a compiled binary with no accessible source on my end and no working verbose/debug logging that I could find, I wasn't able to narrow this further myself. Posting the full evidence trail in case it's useful — happy to run any additional diagnostics if pointed in the right direction. llmfit doctor output available on request (omitted here since it's hardware-specific, not related to this bug).

System: AMD Ryzen 9 9950X, 2x RTX 5060 Ti (32GB total VRAM), 30GB RAM, Ubuntu 24.04

### Expected behavior

llmfit update should successfully cache the config.json metadata for the trending/download-ranked models it fetches, populating hf_models_cache.json with a non-empty models array. Running llmfit fit or llmfit recommend afterward should then return real model recommendations based on that populated cache, rather than an empty result set.

### Actual behavior

llmfit update successfully fetches all 237 model list entries from HuggingFace's trending/download-ranked endpoints, but the "Processing 237 unique models" step silently discards every single one — the cache file gets written but ends up with an empty models array (34 bytes, 0 entries). No error is shown; the tool reports "No new models found — cache is up to date" as if this were the expected steady state, even on a freshly deleted cache. This happens consistently across repeated runs, with and without a HuggingFace token, and with --no-dashboard set.

### Steps to reproduce

Delete the existing cache file: rm ~/.local/share/llmfit/hf_models_cache.json
Run: llmfit update
Observe the output — it reports fetching 237 unique models successfully, then "Saving 0 cached models (0 new)"
Confirm the cache is empty: cat ~/.local/share/llmfit/hf_models_cache.json (shows an empty models array, ~34 bytes)
Run llmfit fit or llmfit recommend — returns no results, since the cache never populated

Reproduced consistently across multiple runs, both with no HuggingFace token present and with a freshly-generated Read-scoped token added at ~/.huggingface/token, and with --no-dashboard explicitly passed to rule out the background dashboard server as a factor.

### Diagnostic report (`llmfit doctor`)

```text
# llmfit doctor report

- llmfit version: 1.1.6
- OS: linux (x86_64)

## Detected by llmfit

SystemSpecs {
total_ram_gb: 30.514923095703125,
available_ram_gb: 28.292381286621094,
total_cpu_cores: 32,
cpu_name: "AMD Ryzen 9 9950X 16-Core Processor",
has_gpu: true,
gpu_vram_gb: Some(15.9287109375),
total_gpu_vram_gb: Some(32.357421875),
gpu_available_gb: None,
gpu_name: Some("NVIDIA GeForce RTX 5060 Ti"),
gpu_count: 3,
unified_memory: false,
backend: Cuda,
gpus: [
GpuInfo { name: "NVIDIA GeForce RTX 5060 Ti", vram_gb: Some(15.9287109375), backend: Cuda, count: 2, unified_memory: false },
GpuInfo { name: "AMD/ATI", vram_gb: Some(0.5), backend: Vulkan, count: 1, unified_memory: false },
],
cluster_mode: false,
cluster_node_count: 0,
}

## nvidia-smi (extended query)

HMM, 16311, NVIDIA GeForce RTX 5060 Ti
HMM, 16311, NVIDIA GeForce RTX 5060 Ti

## nvidia-smi (standard query)

16311, NVIDIA GeForce RTX 5060 Ti
16311, NVIDIA GeForce RTX 5060 Ti

## rocm-smi --showmeminfo vram

(not available: No such file or directory (os error 2))

## rocm-smi --showproductname

(not available: No such file or directory (os error 2))

## sysfs DRM cards

card0: vendor=0x10de device=0x2d04 driver=nvidia mem_info_vram_total=-
card1: vendor=0x10de device=0x2d04 driver=nvidia mem_info_vram_total=-
card2: vendor=0x1002 device=0x13c0 driver=amdgpu mem_info_vram_total=536870912

## lspci (display controllers)

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2d04] (rev a1)
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2d04] (rev a1)
7a:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:13c0] (rev c1)

## Provider app installs

LM Studio installed: false
Docker Desktop installed: false
ollama on PATH: true
```

### llmfit version

1.1.6

### Operating system

Linux

### Affected component

Hardware detection (RAM/CPU/GPU)

### Mode used

TUI (default)

### GPU details (if relevant)

```text
2x NVIDIA GeForce RTX 5060 Ti (16GB VRAM each, ~32GB total), CUDA backend, driver version 580.173.02. A third device is also detected — an AMD/ATI GPU via Vulkan with only 0.5GB VRAM, likely an integrated/software rasterizer being misidentified as a discrete GPU by llmfit's hardware detection (separate minor issue, not the focus of this report, but visible in the llmfit doctor output above).
```

### Additional context

This was investigated with help from an OpenClaw agent (Louie) running qwen3.6:35b-a3b locally, then cross-checked in a separate session. The agent's initial diagnosis (gated-model auth failure) turned out to be a red herring — a single 401 on a known-gated model (meta-llama/Llama-3.1-8B) doesn't explain 237/237 failures on a list that's overwhelmingly non-gated models. Manually testing an ungated model's config.json URL directly with curl confirmed auth was never the actual blocker.

The one lead I couldn't fully chase down: every config.json fetch requires following a 307 redirect to a resolve-cache URL before reaching the real 200 response (confirmed via curl -sIL). If the update command's bulk-fetch path uses an HTTP client that doesn't follow redirects, that would explain the silent 237/237 failure — but I couldn't confirm this from outside a compiled binary with no accessible source and no working RUST_LOG output.

Happy to run further diagnostics if a maintainer can point me toward what would help narrow this down further.