Let a llama session actually be started from the phone

The driver worked and the models could be downloaded, but the spawn screen
had no idea llama.cpp existed: the model field and every extra setting were
gated behind `isClaude`, so a llama provider offered nothing, `model`
arrived null, and the driver refused with "a llama.cpp session needs a
model". The feature was reachable only by curl, which is not what was asked
for.

A llama provider now gets the models this backend has downloaded, as a
picker rather than free text -- there is nothing sensible to type, and a
name that is not on disk is a session that cannot start. Context size and
temperature are there too, blank meaning llama.cpp's own default rather
than a zero. Spawn stays disabled until a model is chosen, because without
one the button could only fail.

**Two bugs that only appeared by pressing the button**, both mine, both
from changing the server without re-driving the app:

- The app sent the setup's *label* where the server had started resolving
  by *id*. The failure was almost self-diagnosing -- `no setup named "this
  machine" -- configured: this machine` -- and that message now says "no
  setup with id" and lists ids, since listing labels was what made it read
  as a contradiction.
- The session header showed `on local`, the id, because the app read
  `setup` where the server had begun sending both `setup` (id) and
  `setupName` (label). The app now carries only the label: nothing in it
  addresses a setup, and holding both is what let it show the wrong one.

Verified by doing it: rediscovered the local machine from the phone so
`local-llama` appeared, spawned a session on Qwen3-0.6B-Q8_0 with a 4096
context, sent "Reply with exactly one word: ready", and it replied "ready"
with 125 tokens counted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw

server/src/session/mod.rs

@@ -456,9 +456,13 @@ impl SessionManager {
             .setup(&spec.setup)
             .with_context(|| {
                 format!(
-                    "no setup named \"{}\" -- configured: {}",
+                    "no setup with id \"{}\" -- configured: {}",
                     spec.setup,
-                    names(inner.config.setups.iter().map(|s| s.name.as_str())),
+                    // Ids, since that is what was looked up. Listing the
+                    // labels made the failure read as a contradiction:
+                    // "no setup named X -- configured: X", when X was a
+                    // label and the id was something else.
+                    names(inner.config.setups.iter().map(|s| s.id.as_str())),
                 )
             })?
             .clone();