docs: simplify lifecycle sections for the converge model

The apply/converge + gateway refactors let the docs collapse a lot:

- design.md §Component Lifecycle: the build→install→deploy three-step
  ("enables and starts services") becomes two moves — develop, then
  `castle apply` (activation polymorphic over the manager). Filesystem
  layout de-duped and corrected (program source is /data/repos/<name>,
  not the long-removed ~/.castle/code).
- registry.md §Lifecycle: three near-identical per-kind flows (service/
  tool/job) collapse into one flow + a "what apply does per manager"
  table. Manager table's "start/stop" column → "how apply activates".
  Fixed stale paths-table rows (code/<name>) and a stale `service run`.
- developing-castle.md endpoint list: `POST /apply` is the one lifecycle
  endpoint; dropped retired `/deploy`; service actions are restart-only;
  added `/config/deployments/{name}/enabled`.

Net −37 lines; no retired-verb or stale-path references remain in docs.

docs/design.md

@@ -416,71 +416,53 @@ Same contract as tools, plus:
 
 ## Component Lifecycle
 
-The path from source to managed process:
+The path from source to managed process is two moves — **develop** (against the
+program) and **converge** (`castle apply`):
 
 ```
-source → [build] → artifact → [install] → available → [deploy] → managed
+source → [dev verbs: build/test/…] → config (programs/ + deployments/) → [castle apply] → running
 ```
 
-Each step is distinct:
+- **Develop** — language-specific dev verbs (`build`, `test`, …) that Castle
+  records but never runs implicitly. Frontends build in place under the repo
+  (`<source>/<dist>/`), served from there — no copy step.
+- **Converge** — `castle apply` reads the config, generates systemd units +
+  Caddyfile entries, then reconciles reality to the desired state: activate what's
+  enabled, restart what changed, deactivate what's disabled. Activation is
+  *polymorphic over the manager* — systemd `enable --now`, `uv tool install` for a
+  tool on PATH, a gateway route for a static — so there is no separate install or
+  start step, and no per-kind verb. `castle apply --plan` shows the diff first.
 
-1. **Build** — Language-specific. Produces an artifact (binary, venv
-   entry point, static bundle). Castle records the commands but doesn't
-   execute them implicitly.
-
-2. **Install** — Makes the artifact available on the system. For tools:
-   `uv tool install` or compiled binary placed in `~/.local/bin/`. For
-   services: same — the binary or entry point is on PATH or in a known
-   location. For frontends: assets built in place under the repo
-   (`<source>/<dist>/`), served from there — no copy.
-
-3. **Deploy** — Materializes the runtime configuration. Reads the
-   program spec, merges with node config, generates systemd units
-   and Caddyfile entries that reference *installed* artifacts — never
-   the source tree. Enables and starts services.
-
-For compiled languages (Rust, Go), build produces a standalone binary
-and install is just placing it in `~/.local/bin/`. For interpreted
-languages (Python, Node), the runtime wrapper (uv, node) handles
-finding the installed artifact.
+Desired on/off is `enabled` on the deployment; the only way to durably stop
+something is `enabled: false` + apply. `castle restart` is the one imperative
+bounce that re-actualizes current state without changing it.
 
 ## Runtime Filesystem Layout
 
-Two roots, each overridable by an env var: `$CASTLE_HOME` (config, code,
-artifacts, secrets; default `~/.castle`) and `$CASTLE_DATA_DIR` (bulk program
-data; default `/data/castle`, kept on a dedicated volume):
+Two roots, each overridable by an env var: `$CASTLE_HOME` (config, artifacts,
+secrets; default `~/.castle`) and `$CASTLE_DATA_DIR` (bulk program data; default
+`/data/castle`, on a dedicated volume). Program source lives separately under
+`/data/repos/<name>/` (`$CASTLE_REPOS_DIR`).
 
 ```
 $CASTLE_HOME/                   ← Config & artifacts (default ~/.castle)
-├── castle.yaml                 ← Global settings; resources under programs/ + deployments/
+├── castle.yaml                 ← Global settings (gateway, repo, agents)
+├── programs/  deployments/     ← One YAML file per program / deployment
 ├── infra.conf                  ← Infrastructure install choices
-├── code/                       ← Program source (your programs)
-│   └── <name>/
-├── artifacts/
-│   ├── specs/                  ← Generated by `castle apply`
-│   │   ├── Caddyfile
-│   │   └── registry.yaml       ← Node config (what's deployed here)
-│   └── content/                ← Built frontend assets
-│       └── castle/         ← (index.html + assets, served at root)
+├── artifacts/specs/            ← Generated by `castle apply`
+│   ├── Caddyfile
+│   └── registry.yaml           ← Node config (what's deployed here)
 └── secrets/                    ← Secret files (NAME → value)
-    └── PROTONMAIL_API_KEY
 
-$CASTLE_DATA_DIR/               ← Persistent service data (default /data/castle)
-└── <name>/
-
-~/.config/systemd/user/         ← Systemd units (standard location)
-├── castle-central-context.service
-├── castle-protonmail.service
-├── castle-protonmail.timer
-└── ...
+/data/repos/<name>/             ← Program source (your programs; absolute source:)
+$CASTLE_DATA_DIR/<name>/        ← Persistent service data (default /data/castle)
+~/.config/systemd/user/         ← Systemd units + timers (castle-*.service/.timer)
 ```
 
 Compiled-language tools (Rust, Go — planned) install their binaries to the
-standard `~/.local/bin/`, not under `$CASTLE_HOME`.
-
-Source (the repo) is referenced only during build and install. Everything
-the runtime touches lives under `$CASTLE_HOME`, `$CASTLE_DATA_DIR`, or standard
-systemd paths.
+standard `~/.local/bin/`. Source is referenced only by dev verbs and while a
+deployment is materialized; everything the runtime touches lives under
+`$CASTLE_HOME`, `$CASTLE_DATA_DIR`, or standard systemd paths.
 
 ## OTP as Design Guide