Add managed llama.cpp engine with Windows CUDA support

[nv-pgoode]

Changelog title

Managed llama.cpp engine

Changelog body

• Install and manage llama.cpp from PAIR, with models retained across runtime uninstall.
• Route llama.cpp requests through the unified proxy to any downloaded model; the engine loads it on demand.
• Prefer the official CUDA build on compatible Windows x64 NVIDIA systems, with a recorded fallback when CUDA cannot be used.

Bumps

• services: minor
• nvpair-cluster-manager: none
• nvpair-engine-manager: minor
• nvpair-errors: none
• nvpair-job-scheduler: minor
• nvpair-manual-nodes: minor
• nvpair-node-info: minor
• nvpair-node-scanner: minor
• nvpair-node-settings: none
• nvpair-proxy: minor
• nvpair-tui: minor
• nvpair-ui-broker: minor
• nvpair-workload-manager: none

Summary

Add managed llama.cpp using the existing Engine Manager, unified proxy and
engine-settings UI. No new service process, no parallel settings implementation,
and no llama.cpp-specific routing rule.

• Install the official llama app into owned runtime storage; start/stop it;
  download/import/load/unload/delete models; cancel model downloads.
• On Windows x64, stage the pinned official CUDA app and runtime archives when
  every detected NVIDIA GPU has compute capability 7.5 or newer, and require a
  working CUDA device probe before promotion. Otherwise retain vendor selection
  and record why CUDA was not used; no local CUDA Toolkit installation is required.
• Keep model files when uninstalling the runtime. Treat external runtimes as
  read-only rather than taking ownership of another installation.
• Use the existing port/settings flow: proxy 8080, engine 8081 by default.
• Load models on demand: the managed router runs serve --models-autoload as a
  fixed argument, so a request for a downloaded model loads it first (the first
  response waits for the load; the router keeps up to four models resident and
  evicts idle ones). Routing eligibility follows the advertised catalog, exactly
  as it does for Ollama and LM Studio; the loaded-model watcher remains for the
  UI's residency indicator and Load/Eject controls.
• Preserve client-disconnect and shutdown cleanup, retry/CORS behavior and
  exactly-once workload terminal delivery, with correct workload attribution.
• Add desktop and TUI engine/model controls, including producer-shaped tests
  for live proxy events and observed model residency.

Excluded: a per-engine switch to turn on-demand loading off (with
loaded-only routing), engine updating, GPU/OS telemetry or chart redesign,
expanded workload browsing, and explicit inference-workload cancellation
controls/API. Those are independent follow-ups, not prerequisites for this
integration.

Non-goals and known limits

• Existing installed runtimes keep their current backend. To move an existing
  Vulkan installation to the CUDA selection path, uninstall and reinstall the
  managed runtime; model files are retained.
• Engine Manager's manifest-only onboarding requirement is not met for three
  llama.cpp capabilities (staged official-app installer, on-disk model cache
  operations, router identity probe); they are engine-specific Go accepted only
  for the bundled manifest and are recorded in spec.md as a current gap.
• The broker's managed-facade coordinator for llama.cpp is a copy of LM
  Studio's with two policy differences; sharing it is left for the next
  managed engine.
• A cold load longer than the proxy's two-minute first-response budget fails
  that request while the router finishes loading; retry or load explicitly.

Review First

Start with services/nvpair-engine-manager/manifests/llamacpp.json (fixed
serve --models-autoload, declared --host/--port controls), then
services/nvpair-proxy/proxy.go subscribedToNode (one eligibility rule for
every facade), services/nvpair-manual-nodes/manager.go probeLlamaCpp, and
the settings regressions in settings_llama_test.go and
services/nvpair-ui-broker/enginesettings_test.go.

Validation

• All 13 GitHub checks pass on 81624e8: desktop checks, SPDX, release intent,
  build-script checks on three operating systems, the full Linux Go component,
  cross-process and tooling suites, and six platform installer builds.
• Local Windows checks on 26271a0: all 15 Go modules build and vet. Full Engine Manager,
  broker, TUI, manual-node, cluster-manager, scheduler, workload-manager, errors,
  node-settings, shared and EAP suites pass; focused scanner/node-info and the
  cross-process external-listener refusal check pass. Network-test limits below.
• Desktop on 26271a0: 260 tests pass, 2 existing skips; typecheck, lint,
  dead-code, service contracts, build-script and SPDX checks pass. Go binaries
  and Electron production bundles build.
• Windows x64 CUDA on 26271a0: fresh managed CUDA installation passed.
  Four consecutive full GPU journeys passed after one earlier streaming-reload
  timeout. The passes cover cold/warm and streamed inference, unload/reload,
  unknown-model rejection, restart persistence, workload attribution and cleanup.
  The initial timeout remains recorded; its cause is not established.
• Windows CPU Desktop/TUI on predecessor f305c3b: actual Load/Unload,
  Start/Stop, proxy inference, completed-workload display and clean exit passed.
  Desktop code is unchanged by 26271a0; this is not a CUDA desktop-UI test.
• Linux x64 NVIDIA on 26271a0: fresh managed install, model pull and first
  proxied inference passed, followed by warm inference, a completed long stream,
  streamed reload after unload, unknown-model rejection, restart persistence and
  five locally attributed completed workloads. Owned compute ran on the selected
  GPU; memory returned to baseline, both brokers exited normally, test ports and
  owned processes closed, and temporary state was removed. Unrelated GPU process
  identities were preserved. The earlier interrupted harness run is retained.
  This establishes the Linux GPU lifecycle, but retained diagnostics do not yet
  establish the exact CUDA backend or offloaded-layer count.
• GitHub Actions built unsigned installers for Windows x64/arm64, Linux
  x64/arm64 and macOS x64/arm64 on 81624e8; these are build results, not native
  hardware qualification for every platform.
• The separately committed desktop startup repair prevents late initial
  snapshots from replacing newer running/stopped events; regression checks pass.
• Test-only follow-up 81624e8 corrects an assertion that assumed Windows
  environment-name case folding on Unix. Canonical cache overrides remain
  rejected on every platform; lowercase aliases are additionally rejected on
  Windows. Production code is unchanged from the hardware-tested 26271a0.

Remaining Qualification

• Linux exact CUDA-backend/offloaded-layer evidence remains unqualified; the
  managed GPU lifecycle and owned-process/data cleanup passed separately.
• The full proxy, scanner, node-info and cross-process suites passed on the
  isolated Linux CI runner. The local Windows gate used the focused network
  selection described above; this does not claim full Windows network-suite coverage.
• CUDA desktop-UI validation, Windows arm64, Linux arm64 and macOS hardware qualification remain.
• The first Windows CUDA streaming-reload timeout was not reproduced in four
  later full runs or a targeted reload probe, but is not explained or erased.

Terve adapted the earlier integration onto the unified proxy. The earlier
llama.cpp work includes the proxy adaptation from #41; #18 and #36 provided
additional design/review context. This does not represent those PRs as merged
unchanged or claim authorship of their underlying shared PAIR infrastructure.

Checklist

• Contribution rules read; every commit has a matching DCO sign-off.
• Required tests and documentation updated; no new dependency added.
• Changed source/filenames/messages checked for private data and internal links.
• Release intent declared; bot-owned versions and changelog unchanged.
• Windows retained-CPU desktop/TUI functional journeys completed.
• Remaining platform/GPU qualification above completed.