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/relationships.md

@@ -1,6 +1,6 @@
 # Relationships: requires, repos, and derived predicates
 
-How castle models the relationships between **programs**, **deployments**, and
+How wildpc models the relationships between **programs**, **deployments**, and
 **repos** — and answers questions like *"is this functional?"*, *"is it fresh?"*,
 *"is it deployed?"* — with the smallest possible amount of stored state.
 
@@ -10,7 +10,7 @@ How castle models the relationships between **programs**, **deployments**, and
 
 A *predicate* is a question we ask about a program or deployment: `functional?`,
 `fresh?`, `deployed?`. None of these are ever stored — each is a **function** over
-data castle already has (git, config, the registry). When a predicate can't be
+data wildpc already has (git, config, the registry). When a predicate can't be
 answered from derived data, find the one missing datum and ask: is it about the
 **thing** (a node property) or about a **relationship** (an edge property)? Encode
 *only* that datum. Everything else stays computed.
@@ -59,17 +59,17 @@ each precondition on its natural layer — a deployment-ref is node-level wiring
 the program). There is no `requires` on the program, and no `kind: system` written
 into a deployment's `requires`.
 
-Only encode a `requires` edge that is **not derivable** and that **castle itself
+Only encode a `requires` edge that is **not derivable** and that **wildpc itself
 must traverse** for an operation (status, bring-up order, group ops). Do **not**
 duplicate what another layer already owns — systemd `Requires=`/`After=` for unit
-ordering, uv/pnpm for build graphs. This is *castle's* slice, uncoupled from any
+ordering, uv/pnpm for build graphs. This is *wildpc's* slice, uncoupled from any
 one package ecosystem.
 
 ### Env is derived *from* `requires`, never scraped *into* it
 
 Reading dependencies out of env strings is unstable (formats vary; a static
 frontend's API URL is baked into its bundle and invisible). The stable direction is
-the reverse: from an encoded `{ref, bind}` deployment requirement castle **generates**
+the reverse: from an encoded `{ref, bind}` deployment requirement wildpc **generates**
 the wiring env — it knows the target's address (`<ref>.<domain>` / its port) and
 projects it into the consumer's env, optionally under the var named by `bind`. Same
 move as `${public_url}`, one step further. Dependency → env, never env → dependency.