docs(deploy): record inter-hub DNS gate finding

workplans/IHUB-WP-0018-railiance01-deployment.md

@@ -399,6 +399,14 @@ expected unauthenticated `401` and OpenAPI exposes `/hubs`,
 directly protects the ops-hub bootstrap gate instead of only checking the
 landing page and generic widget auth gate.
 
+**Authenticated inspection note (2026-06-14):** The stored local Tea token is
+stale for `https://gitea.coulomb.social`, but runner-side inspection succeeded.
+`make runner-status` in `railiance-forge` showed `act_runner` registered to
+`https://gitea.coulomb.social`, started under OpenRC, and carrying the expected
+`self-hosted`/`haskelseed` labels. The runner log shows task `19` for
+`coulomb/inter-hub` starting at `2026-06-14T19:59:19+02:00`, matching the
+`6455902` deploy trigger.
+
 ### R8 — Staged deployment and smoke test
 
 ```task
@@ -435,6 +443,18 @@ Follow the Railiance staged promotion lifecycle:
 `/` returns 200 and contains `inter-hub`, `/api/v2/openapi.json` returns 200,
 and unauthenticated `/api/v2/widgets` returns 401.
 
+**DNS gate finding (2026-06-14):** The deployment workflow did publish and
+deploy `gitea.coulomb.social/coulomb/inter-hub:6455902`; Kubernetes reports the
+`inter-hub` Deployment ready on the COULOMBCORE K3s node
+`92.205.130.254`. An in-cluster probe to
+`http://inter-hub:8000/api/v2/hubs` returned the expected unauthenticated
+`401`, and forcing public TLS to `92.205.130.254` also returned `401`. The
+public DNS record for `hub.coulomb.social`, however, resolves to
+`92.205.62.239`, where `/api/v2/hubs` still returns `404` and OpenAPI lacks the
+bootstrap paths. The remaining production gate is therefore DNS cutover (or an
+intentional kubeconfig rotation to the cluster behind `92.205.62.239`), not a
+runner, build, registry, Helm, or image-content issue.
+
 ### R9 — Document and register
 
 ```task