Add llamacpp support similar to Ollama

[darth-veitcher]

Consider whether separate nodes or refactoring with an adapter pattern.

Background:

llama-server has a router mode — launch it with no -m at all, pointed at --models-dir

(or --models-preset .ini) instead. In that mode it exposes:

•	GET /models — lists models with live status: unloaded, loading, loaded, sleeping, downloading
•	POST /models/load / POST /models/unload — explicit load/unload by name
•	--sleep-idle-seconds — auto-unloads an idle model’s weights and its KV cache from RAM/VRAM after N seconds, without you calling anything

That’s the manual-memory-management API we’re using for Ollama. It landed via PR #18228 (merged 2025-12-21)

[darth-veitcher]

PR #19 is open, implementing this as a genuine adapter pattern (per the design discussion in #16/ADR-007) rather than a parallel set of llama.cpp-specific nodes: LlamaCppProvider implements the same LLMProvider protocol OllamaProvider does, so the existing ChatCompletion/LLMModelSelector/LLMLoadModel/LLMUnloadModel nodes work with it unchanged — the only new node is LlamaCppClient.

Requires llama-server running in router mode (--models-dir/--models-preset), which is what gives it GET /models, POST /models/load/unload — the same manual load/unload primitives comfydv already relies on for Ollama.

Two independent adversarial reviews ran against the diff; the first caught a real gap (a non-router-mode server's errors were being silently swallowed into an empty model list instead of surfacing clearly) which has been fixed and re-verified clear.

One caveat disclosed in the PR: no live llama-server was reachable in this sandboxed dev environment, so the final smoke test against a real server is deferred — flagged in the spec's tasks, not skipped silently. Worth a manual check before/after merge if anyone has a router-mode server handy.

[darth-veitcher]

Correction to my last comment: I said no live `llama-server` was reachable to run the final smoke test — that was wrong, and I should have checked before claiming it. `llama-server` was already installed via Homebrew on this machine.

Went back and actually ran one in router mode against a real local GGUF model, exercising the full lifecycle through the real code (list → load → chat → unload, including repeat load/unload calls to check idempotency). It caught a genuine bug the mocked test suite couldn't: llama-server's router-mode `/models/load`/`/models/unload` endpoints aren't actually idempotent — calling load on an already-loaded model returns an HTTP 400, not the success response the design had assumed. Fixed in the latest commit on PR #19, with the wrong assumption in the design docs corrected to match the real, verified behavior.

[darth-veitcher]

PR #19 merged 2026-07-11 implements this: LlamaCppProvider (src/comfydv/_llm/llamacpp_provider.py) implements the LLMProvider protocol alongside OllamaProvider, plus the new LlamaCppClient node. Verified on main: files exist, and tests/test_llamacpp.py + tests/test_llamacpp_provider.py pass (34 tests). Closing as completed.