Manager-first deployment model: split runner, merge service/job, frontend→static

Replace the conflated `runner` axis with two orthogonal ones: `manager`
(systemd|caddy|path|none) — who supervises/realizes a deployment — and, for
systemd only, a nested `launcher` (python|command|container|compose|node) — how
the process starts. ServiceSpec and JobSpec collapse into one manager-
discriminated DeploymentSpec union (Systemd/Caddy/Path/Remote); the services/
and jobs/ config dirs collapse into one deployments/ dir. The human "kind"
(service|job|tool|static|reference) is fully derived (kind_for), never stored —
the frontend kind is renamed static. behavior is gone.

- core: DeploymentSpec union + LaunchSpec + kind_for; legacy-aware loader
  normalizes old runner shapes; CastleConfig.deployments with derived
  services/jobs/tools views; registry.Deployment carries manager/launcher/kind.
- cli: service/job/tool as filtered views + a deployment group; --behavior→--kind,
  create --runner→--launcher; lifecycle dispatches over config.deployments.
- castle-api: /deployments primary with /services,/jobs as views; summaries
  derive kind; PUT/DELETE /config/deployments/{name} (services/jobs aliased).
- app: KindBadge, frontend→static everywhere, pick-a-kind creation wizard,
  per-kind config editors.
- docs: single deployments/ layout, manager/launcher, static kind throughout.

Live migration verified byte-identical: regenerated Caddyfile and every unit
ExecStart line unchanged, so nothing restarted. Suites: core 124, cli 25,
castle-api 55; dashboard build + type-check clean.

docs/stacks/python-fastapi.md

@@ -103,42 +103,42 @@ class Settings(BaseSettings):
 settings = Settings()
 ```
 
-Castle passes config via env vars in castle.yaml:
+Castle passes config via env vars in the deployment's `defaults.env`:
 
 ```yaml
-programs:
-  my-service:
-    description: Does something useful
-    source: /data/repos/my-service
-    stack: python-fastapi
-    behavior: daemon
-
-services:
-  my-service:
-    program: my-service
-    run:
-      runner: python
-      program: my-service
-    expose:
-      http:
-        internal: { port: 9001 }
-        health_path: /health
-    proxy: true   # expose at my-service.<gateway.domain>
-    manage:
-      systemd: {}
+# programs/my-service.yaml
+description: Does something useful
+source: /data/repos/my-service
+stack: python-fastapi
+```
+```yaml
+# deployments/my-service.yaml (manager: systemd → kind: service)
+program: my-service
+manager: systemd
+run:
+  launcher: python
+  program: my-service
+expose:
+  http:
+    internal: { port: 9001 }
+    health_path: /health
+proxy: true   # expose at my-service.<gateway.domain>
+manage:
+  systemd: {}
 ```
 
 The env a service runs with is exactly what's in `defaults.env` — castle injects
 nothing implicitly. Map the vars your settings read (above, `env_prefix:
 "MY_SERVICE_"` → `MY_SERVICE_PORT`/`MY_SERVICE_DATA_DIR`) to castle's computed
-values with the `${port}`/`${data_dir}` placeholders:
+values with the `${port}`/`${data_dir}` placeholders — add to
+`deployments/my-service.yaml`:
 
 ```yaml
-    defaults:
-      env:
-        MY_SERVICE_PORT: ${port}            # = expose.http.internal.port
-        MY_SERVICE_DATA_DIR: ${data_dir}    # = $CASTLE_DATA_DIR/my-service
-        CENTRAL_CONTEXT_URL: http://localhost:9001
+defaults:
+  env:
+    MY_SERVICE_PORT: ${port}            # = expose.http.internal.port
+    MY_SERVICE_DATA_DIR: ${data_dir}    # = $CASTLE_DATA_DIR/my-service
+    CENTRAL_CONTEXT_URL: http://localhost:9001
 ```
 
 `castle program create` scaffolds the `${port}`/`${data_dir}` lines for you.