gateway: serve the dashboard at wild-pc.<domain>, 404 unrouted subdomains

The dashboard's deployment kept the pre-rename name `wildpc`, so it was
published at wildpc.<domain> while everything else had moved to Wild PC
naming. Rename the deployment and its program to `wild-pc` (the subdomain
is the deployment name) and follow the `_DASHBOARD` constant in both the
Caddyfile generator and doctor — that constant also drives the `:9000`
redirect and doctor's `wildpc program build` hint, which is why the
program is renamed alongside the deployment.

Browsing the old name exposed a second problem: in acme mode every route
lives inside one `*.<domain>` wildcard site, so an unrouted host still
matches the site and completes its TLS handshake. Caddy then ran off the
end of the block and returned a bare 200 with an empty body — a typo'd or
renamed subdomain looked *up* in a browser while rendering nothing. Each
wildcard site now ends with an unmatched `handle` that responds 404.

The API subdomain is untouched: the dashboard derives its API origin by
stripping the first label, so wild-pc.<domain> still resolves to
wildpc-api.<domain>, and the WebSocket origin gate matches on
gateway.domain rather than a hostname.

Also seed the bootstrap dashboard deployment with the `requires:
wildpc-api` block the live deployment already carried, so a fresh install
declares the dependency.

app/src/services/api/client.ts

@@ -1,5 +1,5 @@
 // Resolve the wildpc-api base URL. The gateway serves each service at its own
-// subdomain (<name>.<domain>), so when the dashboard runs at wildpc.<domain>
+// subdomain (<name>.<domain>), so when the dashboard runs at wild-pc.<domain>
 // the API lives at wildpc-api.<domain> — a cross-origin call (wildpc-api allows
 // CORS *). When served at a bare host (dev, or the off-mode :9000 gateway), the
 // API is reachable same-origin at /api.