Add a server "コンテナ" rail entry and consolidate Docker/Podman/Kubernetes templates into it

[tvna]

Summary

Owner-requested follow-up to #501. Add a dedicated left-nav rail entry for
server's コンテナ sub-category (matching the existing
server-debian/server-rhel split), and consolidate every container-runtime/
orchestration template into that single コンテナ sub-category: the existing
Docker (8) and Podman (2) sub-categories, plus 4 templates whose core
subject is generic container/Kubernetes infrastructure currently
miscategorized under ai/ops.

Background

• server's subCategory: "コンテナ" already exists in the drift-gate
  allow-list (tests/unit/test_template_taxonomy.py) but has only one member
  (k3s-single-node); Docker (8 templates) and Podman (2 templates) are
  separate sub-categories in the same server domain.
• web/src/components/Library.tsx's left rail already splits server into
  server-common/server-debian/server-rhel (added after refactor(templates): split server subCategory by Linux distro family, audit network vendor tags #611's
  distro-family split); there is no dedicated entry for container templates,
  so they render under the generic server-common bucket today.
• Content audit (full .j2 bodies read, not just titles) found 4 templates
  outside server whose core subject is generic container/Kubernetes
  infrastructure rather than the AI/ops topic their current category implies:
  • ai/GPUコンテナ: nvidia-container-toolkit — sole member of that
    sub-category; content is Docker+NVIDIA Container Toolkit runtime
    configuration, and the template's own body explicitly contrasts itself
    with docker-basic-ops (a server/Docker template).
  • ai/GPUクラスタ: k8s-gpu-operator-deploy, k8s-gpu-node-drain —
    content is 100% generic Kubernetes cluster administration (Helm install,
    kubectl cordon/drain/uncordon); GPU is only the workload label. The
    other 8 GPUクラスタ members (Slurm, NCCL, DCGM, NVLink, InfiniBand, rack
    power) stay put — genuinely AI/GPU-cluster hardware/scheduling topics, not
    container orchestration.
  • ops/ポリシー統制: opa-kubernetes-admission — one of a cohesive
    15-member OPA/Rego policy series (opa-rego-policy-authoring,
    opa-api-authorization, opa-terraform-iac-policy,
    opa-bundle-distribution, opa-decision-log-audit,
    opa-policy-test-cicd, opa-policy-conflict-triage,
    opa-envoy-external-authz, opa-data-document-management,
    opa-policy-rollout-change, opa-performance-bundle-triage,
    opa-policy-governance-drill, opa-secrets-access-policy,
    opa-server-deployment-hardening, plus opa-kubernetes-admission
    itself), all built the same day covering "OPA applied to a different
    target system." Owner decision (raised and confirmed during
    brainstorming): move it anyway, prioritizing "content is
    Kubernetes-specific" over "stays with its OPA siblings" — an accepted
    trade-off, not an oversight. The other 14 members are unaffected.
• Templates that merely deploy AI-domain software via Docker (Qdrant, Milvus,
  W&B, Langfuse, LangGraph, Open WebUI, Triton, TGI — 10 templates) stay in
  ai: the software identity is the primary axis there, not the container
  packaging. Same reasoning keeps linux-bridge-setup/
  wireguard-container-gateway in network (bridge/VPN is the subject, not
  container tech) and trivy-image-scan/lynis-container-image-audit in
  server/Debian系 (already correctly audit-classified by refactor(templates): split server subCategory by Linux distro family, audit network vendor tags #611's
  distro-lock rule).

Plan

• web/src/lib/templates.ts: change subCategory (and category for the 4
  cross-domain ones) for 15 templates total so they all read
  category: "server", subCategory: "コンテナ". Full id-level mapping in the
  design doc.
• tests/unit/test_template_taxonomy.py: remove "Docker"/"Podman" from
  server's allow-list (0 members after consolidation) and "GPUコンテナ"
  from ai's allow-list (0 members after consolidation); "GPUクラスタ"
  (10→8) and "ポリシー統制" (15→14) keep their remaining members and stay
  in the allow-list unchanged.
• web/src/components/Library.tsx: add a server-container rail entry
  (サーバ (コンテナ), reusing the server icon, same サーバ group,
  positioned after server-rhel); extend server-common's exclusion set
  (rename SERVER_DISTRO_LABELS → a more general name) to also exclude
  コンテナ.
• web/src/components/Library.test.tsx: update the "exactly 3 server
  entries" assertion to 4, and the EXPECTED rail-count table
  (server-common 227→216, new server-container: 15, ai 117→114, ops
  44→43; all: 794 unchanged).

Full design doc: docs/superpowers/specs/2026-07-31-server-container-consolidation-design.md.
Full implementation plan: docs/superpowers/plans/2026-07-31-server-container-consolidation.md.

Refs #501.

---

Edit: corrected the ops/ポリシー統制 sibling count above (was
miscounted as 14 total/13 remaining; actual is 15 total/14 remaining) after
an independent spec-compliance review caught the discrepancy against the
real data. Doesn't change the plan or any code — only 1 template
(opa-kubernetes-admission) ever moves out of ops either way.