fix(distributed): backend discovery hid worker-installed backends behind the controller's filesystem

[localai-bot]

On a distributed controller, backend discovery filters on installed-state derived from the controller's own filesystem. A backend lives on the worker node that runs it, so anything an admin installed on a GPU worker reads as "not installed" and disappears from the listing.

Installed is set at core/gallery/gallery.go:552 via getGalleryElements's callback, which for backends is systemBackends.Exists(backend.GetName()) — a pure local directory scan.

Why this surfaces now

#10947 fixed the sibling filter on these same endpoints: capability was also evaluated against the controller, so GPU-only meta backends were dropped entirely on a GPU-less pod. That fix made this one sharper rather than causing it. Before, the backend was hidden by the capability filter; now it becomes listable and the installed-state filter drops it anyway, so the dropdown is still empty.

Two filters, one root cause, one previously fixed.

Fix

The controller cannot derive worker install state locally, but it already aggregates exactly this: nodes.DistributedBackendManager.ListBackends() fans out over NATS, skips pending/offline/draining nodes, and builds SystemBackend.Nodes[] with node_name/node_status — which is what GET /backends renders today. Discovery now reuses that active BackendManager rather than growing a second path.

Mirrors #10947's structure one-for-one: a ClusterInstalledProvider, a resolveClusterInstalled that degrades to local-only on a nil provider or an error, and routes.ClusterInstalledProviderFor(app) returning nil outside distributed mode.

Three surfaces shared the root cause and route through one helper now:

• GET /backends/available (installed is now cluster-wide)
• GET /api/fine-tuning/backends
• GET /api/quantization/backends

Matching is on b.Name, identical to the existing local systemBackends.Exists(GetName()) semantics — no new matching rules introduced.

Response shape

Stays a boolean, not an installed-on-N-of-M count. The fine-tune and quantization responses carry no install field at all — they are dropdown feeds, where a count would be noise. /backends/available already exposes a boolean, and the authoritative per-node breakdown is one endpoint over at GET /backends nodes[], with node-level action at POST /api/nodes/:id/backends/install. A count would mean a schema change plus UI work across three surfaces to express something already available elsewhere.

Compatibility

A nil provider (single-node) leaves the local filesystem as the only source and reproduces today's listing exactly; a registry error degrades to that same listing rather than blanking the catalog or 500-ing, following the #10947 precedent. Both are covered by specs.

Contract audit across the whole repo including tests/e2e/ (no build tags there): the three endpoint constructors are referenced only from core/http/routes/{finetuning,quantization,localai}.go and the two #10947 test files. No e2e spec pins them; the React UI consumes them by URL only.

Testing

Red first, with providers accepted but ignored so the failures are behavioral rather than compile errors:

Summarizing 3 Failures:
  [FAIL] fine-tune backends [It] lists a backend installed only on a worker node
  [FAIL] quantization backends [It] lists a backend installed only on a worker node
  [FAIL] GET /backends/available [It] reports a worker-installed backend as installed
Ran 211 of 211 Specs — 208 Passed | 3 Failed

Green:

ok  core/http/endpoints/localai  25.997s
ok  core/http/routes              0.302s

Full pre-commit gate: make lint 0 issues; coverage-check: OK — coverage rose to 53.3% (baseline 48.5%). Baseline untouched.

Fixes #10953

---

🤖 Generated with Claude Code