fix(templates): make the shipped templates match reality

The templates are what `create server --from-template` builds from and what
mcpd seeds on start, so drift there ships broken servers. Nothing ever read
these files in a test, and they had rotted badly.

- grafana: GRAFANA_URL now defaults to the in-cluster ClusterIP and the
  description spells out why the public hostname is wrong — reaching a
  co-located Grafana over its ingress hairpins through the per-host Envoy L7
  policy, which drops the caller's identity and returns a bare `Access denied`
  403 with a perfectly valid token. That cost a day of looking at the token.
- unifi-network: was wrong on every field that mattered. `runtime: python`
  for an npm package, an env contract (UNIFI_HOST/USERNAME/PASSWORD) the
  package doesn't read, and no probe. Now UNIFI_TARGETS with the
  classic-vs-unifi_os distinction and the :8443 egress caveat written down.
- docmost, gitea: both carried "health check disabled" comments citing a
  limitation of the old docker-exec probe, which readiness-via-proxy removed.
  Both probes verified against the live servers. gitea uses search_repos, not
  get_me, because get_me needs a `read:user` scope a repo-scoped token lacks.
- filesystem: packageName was `@anthropic/filesystem-mcp`, which 404s on npm —
  the template could never have installed. Points at the real package.
- terraform: deleted. `@anthropic/terraform-mcp` 404s too and there is no
  npm-published replacement to point it at.
- node-red: deleted, the service is gone.

Two supporting fixes:
- The seeder declared no `runtime` field and never wrote the column, so a
  template asking for the python runner silently seeded as null and got node.
- A new templates test reads every shipped file: schema-valid, a runner the
  orchestrator knows, some way to actually start, unique env names, and a
  readiness probe (without one an instance can only ever report `live`).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0114dg56YmVacyqhp5fitcTb

templates/gitea.yaml

@@ -7,7 +7,18 @@ repositoryUrl: https://gitea.com/gitea/gitea-mcp
 # No command: the image's entrypoint IS the MCP server. mcpd attaches to PID 1
 # stdin/stdout (attach mode) rather than exec-ing a new process. The image is
 # distroless and has no node/shell, so exec-based STDIO would fail.
-# Health check disabled: STDIO health probe requires node in the container.
+healthCheck:
+  # search_repos is a real Gitea API call, deliberately chosen over get_me:
+  # get_me needs the `read:user` token scope, which a repo-scoped token won't
+  # have, so it would fail for a bookkeeping reason rather than a real one.
+  # (The "probe requires node in the container" caveat that used to sit here
+  # described the old docker-exec probe; readiness goes through the MCP proxy
+  # now, so a distroless image is fine.) Verified against the live server.
+  tool: search_repos
+  arguments:
+    query: mcpctl
+  intervalSeconds: 60
+  timeoutSeconds: 10
 env:
   - name: GITEA_HOST
     description: Gitea instance URL (e.g. https://gitea.example.com)