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/dns-and-tls.md

@@ -1,6 +1,6 @@
-# DNS & TLS in Castle
+# DNS & TLS in Wild PC
 
-How services on a Castle node become reachable by name and trusted over HTTPS —
+How services on a Wild PC node become reachable by name and trusted over HTTPS —
 while staying **internal-only** (no external exposure). This is the conceptual
 companion to the field-level gateway reference in
 [registry.md](registry.md#proxy--how-the-gateway-routes-to-it).
@@ -8,10 +8,10 @@ companion to the field-level gateway reference in
 Two independent questions decide whether `https://foo.example/` works from a
 browser on your LAN:
 
-1. **Resolve** — does the name `foo.example` point at the Castle node? *(DNS)*
+1. **Resolve** — does the name `foo.example` point at the Wild PC node? *(DNS)*
 2. **Trust** — is the certificate the node serves one the browser accepts? *(TLS)*
 
-Castle answers #1 by leaning on your LAN's own DNS, and #2 with a per-node choice
+Wild PC answers #1 by leaning on your LAN's own DNS, and #2 with a per-node choice
 of two TLS modes. They're orthogonal: you pick a resolution strategy and a trust
 strategy, and any working combination is fine.
 
@@ -34,7 +34,7 @@ making those subdomains **resolve** (DNS) and be **trusted** (TLS).
 ## DNS: making a name resolve to the node
 
 A subdomain does nothing until it resolves **to this node** on the clients that
-browse it. Castle does **not** run DNS; you add one record to your **LAN's DNS
+browse it. Wild PC does **not** run DNS; you add one record to your **LAN's DNS
 server** — usually the router. A single **wildcard** covers every subdomain, so new
 services need no further DNS edits:
 
@@ -54,7 +54,7 @@ trusted (real cert) yet reachable only from the LAN, never the internet.
 
 ## TLS: two trust modes
 
-`gateway.tls` (in `castle.yaml`) picks how host routes are served. It's a per-node
+`gateway.tls` (in `wildpc.yaml`) picks how host routes are served. It's a per-node
 choice.
 
 | `gateway.tls` | What the browser gets | Client setup | Use when |
@@ -122,7 +122,7 @@ origin — moving a service onto HTTPS changes its origin.
    (§DNS). Verify: `dig +short <name>.<domain>` → the node's IP.
 3. **Set `gateway.tls: acme`** (with `domain`/`acme_email`), plus the operational
    prerequisites (below).
-4. **Deploy & reload:** `castle apply` regenerates the Caddyfile and reloads Caddy.
+4. **Deploy & reload:** `wildpc apply` regenerates the Caddyfile and reloads Caddy.
 5. **Update the app's origin allowlist** if it has one (§secure context).
 
 ## Operational prerequisites
@@ -137,14 +137,14 @@ a DNS token.
 - **`acme` only — a DNS-plugin Caddy.** Stock Caddy has no DNS-provider modules.
   Build one: `./install.sh --with-dns-plugin=<provider>` (uses `xcaddy`, installs
   to `/usr/local/bin/caddy`, which precedes the apt binary on `PATH`, so the
-  gateway picks it up on the next deploy). Castle now owns updates to that binary.
+  gateway picks it up on the next deploy). Wild PC now owns updates to that binary.
 - **`acme` only — a provider API token.** Store it as a secret
-  (`~/.castle/secrets/<TOKEN_NAME>`, scope: the DNS provider's "edit DNS records"
+  (`~/.wildpc/secrets/<TOKEN_NAME>`, scope: the DNS provider's "edit DNS records"
   permission for your zone) and map it into the gateway service env in
-  `deployments/castle-gateway.yaml` (`defaults.env`), so Caddy reads it as
-  `{env.<TOKEN_NAME>}`. `castle apply` warns if the domain, env var, or secret is
+  `deployments/wildpc-gateway.yaml` (`defaults.env`), so Caddy reads it as
+  `{env.<TOKEN_NAME>}`. `wildpc apply` warns if the domain, env var, or secret is
   missing.
-- **`acme` — stage first.** Set `CASTLE_ACME_STAGING=1` at deploy to use Let's
+- **`acme` — stage first.** Set `WILDPC_ACME_STAGING=1` at deploy to use Let's
   Encrypt's staging CA (generous rate limits) while verifying issuance, then unset
   it and redeploy for a browser-trusted production cert.