A setup is a machine, and it carries what that machine can run

Providers and hosts were two independent lists, and a session named one of
each. They were never independent: a provider only exists on a machine
where that program is installed, so the spawn screen offered the whole
cross-product, including "the Claude CLI on the box that hasn't got it".
The picker could not know, because nothing in the model said.

Now a setup is a machine -- optional ssh, plus the providers it has -- and
spawning is two choices in order: pick a setup, then one of its providers.
The impossible pairs stop being expressible rather than being validated
against. Provider names are unique within a setup and only within one, so
two machines can each have a `claude-cli`, which was previously either a
name collision or two entries called things like "claude" and "claude on
the vm".

It also settles the "Run on" problem properly. That control was offered for
every provider but honoured only by the Claude driver -- an echo session
sent to a host ran locally and said otherwise. There is no such control
now: the machine is chosen first, and echo is a provider of the setup with
no ssh, where it belongs, since it runs in-process and has no transport to
cross.

The built-in echo provider is gone as a concept. It used to be conjured at
read time and never written to the file, which meant a provider nobody
could see or edit; it is now seeded into the config on first run alongside
claude-cli. What the file says is what there is, and deleting it is a
choice rather than a state to be repaired.

A config in the old shape is refused with instructions rather than loaded.
`Config` defaults unknown fields away, so `providers:` and `hosts:` would
otherwise have vanished into an empty config that was then seeded over --
a migration nobody would notice until their setups were gone.

Verified against a running server and on the emulator: a fresh install
seeds "this machine" with echo and claude-cli and the file reads cleanly;
a two-setup config lists both with their own providers; spawning on a
setup works and the session row names it; asking for a provider a setup
lacks says which it offers, and an unknown setup says which exist. On the
phone, selecting "dev vm" narrows the provider chips to that machine's one
and shows its address.

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

server/src/main.rs

@@ -199,11 +199,17 @@ async fn main() -> Result<()> {
     );
     tracing::info!("config: {}", config_path.display());
     tracing::info!("models: {}", models_dir.display());
-    for provider in manager.providers() {
-        tracing::info!("  provider {} ({:?})", provider.name, provider.kind);
-    }
-    for host in manager.hosts() {
-        tracing::info!("  host {} -> {}", host.name, host.address);
+    for setup in manager.setups() {
+        match &setup.ssh {
+            Some(ssh) => tracing::info!("  setup \"{}\" -> {}", setup.name, ssh.address),
+            // No parenthetical naming the local machine: the default
+            // setup is *called* "this machine", and the line read
+            // "setup this machine (this machine)".
+            None => tracing::info!("  setup \"{}\" runs here", setup.name),
+        }
+        for provider in &setup.providers {
+            tracing::info!("    provider {} ({:?})", provider.name, provider.kind);
+        }
     }
     for info in manager.sessions() {
         tracing::info!(