Rename Castle -> Wild PC across the repo

Repo-side rename only (Phases 1-3 of the migration plan); the live box
(~/.castle, systemd units, /data/castle, domains) is a separate cutover.

- Slug `castle` -> `wildpc`: CLI command, module names (wildpc_core/cli/api),
  dist names, entry point `wildpc = wildpc_cli.main:main`.
- Identifiers: CastleConfig/NATSClient/DirError/MDNS -> Wildpc*.
- Env/constants: CASTLE_* -> WILDPC_*; ~/.castle -> ~/.wildpc, castle.yaml ->
  wildpc.yaml, /data/castle -> /data/wildpc.
- Systemd UNIT_PREFIX castle- -> wildpc-; own programs castle-api/gateway/etc.
- Display prose "Castle" -> "Wild PC" in docs, agent-guide files, README, frontend.
- Package dirs and bootstrap yaml renamed via git mv; lockfiles regenerated;
  redundant nested uv.lock files dropped (workspace root lock is authoritative).

Tests: core 273, cli 47, wildpc-api 120 all pass. Frontend type-checks + builds.
Fixed a stale test fixture (secret_env_path kind arg) broken pre-rename.

docs/stacks/python-fastapi.md

@@ -1,15 +1,15 @@
-# Web APIs in Castle
+# Web APIs in Wild PC
 
 > **This is a stack — creation-time guidance for writing _new_ FastAPI services.**
-> A stack is a template + conventions, not a runtime requirement. `castle program create
+> A stack is a template + conventions, not a runtime requirement. `wildpc program create
 > --stack python-fastapi` scaffolds from it and seeds the program's default
-> dev-verb commands. An existing service adopted with `castle program add` doesn't need
+> dev-verb commands. An existing service adopted with `wildpc program add` doesn't need
 > this stack — it declares its own `commands:`. See @docs/registry.md
 > for `commands:`, `stack:` (optional), and `repo:`.
 
-How to build Python web APIs as castle service components. Based on the
+How to build Python web APIs as wildpc service components. Based on the
 patterns used in [wild-cloud/api](https://github.com/civilsociety-dev/wild-cloud)
-and existing castle services (central-context, notification-bridge, event-bus).
+and existing wildpc services (central-context, notification-bridge, event-bus).
 
 ## Stack
 
@@ -103,7 +103,7 @@ class Settings(BaseSettings):
 settings = Settings()
 ```
 
-Castle passes config via env vars in the deployment's `defaults.env`:
+Wild PC passes config via env vars in the deployment's `defaults.env`:
 
 ```yaml
 # programs/my-service.yaml
@@ -127,9 +127,9 @@ manage:
   systemd: {}
 ```
 
-The env a service runs with is exactly what's in `defaults.env` — castle injects
+The env a service runs with is exactly what's in `defaults.env` — wildpc 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
+"MY_SERVICE_"` → `MY_SERVICE_PORT`/`MY_SERVICE_DATA_DIR`) to wildpc's computed
 values with the `${port}`/`${data_dir}` placeholders — add to
 `deployments/my-service.yaml`:
 
@@ -137,11 +137,11 @@ values with the `${port}`/`${data_dir}` placeholders — add to
 defaults:
   env:
     MY_SERVICE_PORT: ${port}            # = expose.http.internal.port
-    MY_SERVICE_DATA_DIR: ${data_dir}    # = $CASTLE_DATA_DIR/my-service
+    MY_SERVICE_DATA_DIR: ${data_dir}    # = $WILDPC_DATA_DIR/my-service
     CENTRAL_CONTEXT_URL: http://localhost:9001
 ```
 
-`castle program create` scaffolds the `${port}`/`${data_dir}` lines for you.
+`wildpc program create` scaffolds the `${port}`/`${data_dir}` lines for you.
 
 ## Application entry point
 
@@ -300,10 +300,10 @@ Mapping convention:
 
 ## Storage
 
-Castle services use filesystem storage with JSON metadata sidecars:
+Wild PC services use filesystem storage with JSON metadata sidecars:
 
 ```
-$CASTLE_DATA_DIR/my-service/     # default /data/castle/my-service/
+$WILDPC_DATA_DIR/my-service/     # default /data/wildpc/my-service/
 └── bucket/
     ├── item-name
     └── item-name.meta.json
@@ -447,11 +447,11 @@ uv run ruff format .        # Format
 
 ## Scaffolding
 
-`castle program create` generates all of this automatically:
+`wildpc program create` generates all of this automatically:
 
 ```bash
-castle program create my-service --stack python-fastapi --description "Does something useful"
+wildpc program create my-service --stack python-fastapi --description "Does something useful"
 ```
 
-See @docs/registry.md for manifest fields, castle.yaml structure,
-and the full service lifecycle (`castle apply`, logs).
+See @docs/registry.md for manifest fields, wildpc.yaml structure,
+and the full service lifecycle (`wildpc apply`, logs).