feat(registry): complete ATLAS-WP-0002 T02, T03, T06

T02: remove inherited capability.infotech.repo-template and template consumer
docs (statehub-register, template-validation-checklist); add
capability.infotech.config-surface-atlas and rewrite capabilities.yaml.

T03: seed 4 configuration surfaces (state-hub api-config, ops-warden
routing-catalog, reuse-surface federation-sources, ops-bridge tunnel-config)
with registry/indexes/surfaces.yaml; source-linked, no values, secret deps by
reference.

T06: add tools/validate_registry.py (schema + index gate), Makefile (make
validate), and .github/workflows/validate.yml (GitHub + Gitea Actions);
document in stack-and-commands. Verified malformed entries are rejected.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

registry/surfaces/surface.infotech.ops-bridge.tunnel-config.md

@@ -0,0 +1,43 @@
+---
+id: surface.infotech.ops-bridge.tunnel-config
+name: ops-bridge SSH tunnel configuration
+kind: infra-state
+summary: Declares the reverse SSH tunnels (local/remote port maps) that expose State Hub and MCP services to remote machines.
+owner: ops-bridge
+status: active
+scope:
+  allowed_layers: [company, environment, installation]
+  default_layer: installation
+mutability: deploy-time
+security_class: operational
+schema:
+  type: object
+  validator: ~/ops-bridge/schemas/tunnel.schema.yaml
+sources:
+  - repo: ops-bridge
+    path: config/tunnels.yaml
+    role: installation-overlay
+relations:
+  consumed_by:
+    - service.ops-bridge
+  overrides: []
+  depends_on_secret:
+    - ops-bridge/ssh-cert
+  related_to:
+    - surface.infotech.state-hub.api-config
+evidence:
+  last_seen: '2026-06-26'
+  discovery_method: manual
+  change_log_ref: ATLAS-WP-0002-T03
+---
+
+# ops-bridge SSH tunnel configuration
+
+ops-bridge maintains reverse SSH tunnels that expose the State Hub API and MCP
+endpoints to remote machines (the remote port map: State Hub API `:18000`, MCP
+`:18001`). This surface maps that tunnel configuration as **infra-state**.
+
+- **Source of truth:** the `ops-bridge` repo tunnel config; SSH certs are a secret
+  reference (`depends_on_secret`), signed by ops-warden, never stored here.
+- **Relation:** exposes `surface.infotech.state-hub.api-config` to remote workers.
+- **Mutability:** deploy-time — tunnel changes are brought up via `bridge up`.

registry/surfaces/surface.infotech.ops-warden.routing-catalog.md

@@ -0,0 +1,44 @@
+---
+id: surface.infotech.ops-warden.routing-catalog
+name: ops-warden credential routing catalog
+kind: policy
+summary: Catalog mapping credential/access needs to their owning subsystem (who issues what), consumed via `warden route`.
+owner: ops-warden
+status: active
+scope:
+  allowed_layers: [company, platform]
+  default_layer: company
+mutability: deploy-time
+security_class: policy
+schema:
+  type: object
+  validator: ~/ops-warden/registry/routing/catalog.schema.yaml
+sources:
+  - repo: ops-warden
+    path: registry/routing/catalog.yaml
+    role: company-baseline
+relations:
+  consumed_by:
+    - service.warden-cli
+  overrides: []
+  depends_on_secret: []
+  related_to:
+    - surface.infotech.state-hub.api-config
+evidence:
+  last_seen: '2026-06-26'
+  discovery_method: manual
+  change_log_ref: ATLAS-WP-0002-T03
+---
+
+# ops-warden credential routing catalog
+
+The credential routing catalog answers "who owns this credential need?" — SSH certs
+(ops-warden), API keys/DB passwords (OpenBao), login/OIDC (key-cape), etc. It is a
+**routing policy** surface: it carries pointers, never secret values.
+
+- **Source of truth:** `ops-warden/registry/routing/catalog.yaml`; consumed via
+  `warden route find/show`.
+- **Boundary:** this surface maps the catalog's existence, owner, and scope; secret
+  values are never stored here (`security_class: policy`, no `depends_on_secret`).
+- **Why indexed:** credential routing is high-frequency and high-risk; the atlas
+  records where the routing policy lives and who owns it.

registry/surfaces/surface.infotech.reuse-surface.federation-sources.md

@@ -0,0 +1,44 @@
+---
+id: surface.infotech.reuse-surface.federation-sources
+name: reuse-surface federation sources
+kind: app-config
+summary: Federation roster and source list that define which registries reuse-surface aggregates, including the reserved id namespaces.
+owner: reuse-surface
+status: active
+scope:
+  allowed_layers: [company, platform, installation]
+  default_layer: company
+mutability: hot-reloadable
+security_class: operational
+schema:
+  type: object
+  validator: ~/reuse-surface/schemas/federation.schema.yaml
+sources:
+  - repo: reuse-surface
+    path: registry/federation/sources.yaml
+    role: company-baseline
+  - repo: reuse-surface
+    path: registry/federation/local-repo-roster.yaml
+    role: installation-overlay
+relations:
+  consumed_by:
+    - service.reuse-surface-hub
+  overrides: []
+  depends_on_secret: []
+  related_to:
+    - surface.infotech.state-hub.api-config
+evidence:
+  last_seen: '2026-06-26'
+  discovery_method: manual
+  change_log_ref: ATLAS-WP-0002-T03
+---
+
+# reuse-surface federation sources
+
+The federation sources configure which registries reuse-surface aggregates and the
+id namespaces each owns. config-atlas federates here as a typed peer (the `surface.*`
+namespace reservation is ATLAS-WP-0002-T05).
+
+- **Source of truth:** `reuse-surface/registry/federation/{sources,local-repo-roster}.yaml`.
+- **Why indexed:** this is the surface that governs cross-registry interoperability;
+  config-atlas's own discoverability depends on it.