REUSE-WP-0017-T06: diagnose config-atlas publish blocker

Two conflated issues: (1) the raw-URL 303 redirect is already followed
correctly by establish.py's urllib-based probe -- re-running
publish-check now passes; the stale roster fail was from the 2026-06-16
sweep, not a live issue. (2) config-atlas was never actually registered
with the production hub (absent from the 60 sources at
reuse.coulomb.social/v1/federated despite hub_registered: true in the
roster) -- corrected to false. Local publish pass is now 61/61; hub
registration itself is blocked on REUSE_SURFACE_TOKEN, which has no
routing catalog entry -- needs Bernd to provide or route it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

workplans/REUSE-WP-0017-capability-coverage-campaign.md

@@ -205,17 +205,41 @@ state_hub_task_id: "56b68b6f-4dca-4fed-925f-d20783dc40d9"
 
 ```task
 id: REUSE-WP-0017-T06
-status: todo
+status: progress
 priority: medium
 state_hub_task_id: "1a04b60a-b982-4b5f-ae20-955bc88d4204"
 ```
 
-- Diagnose the 303 on the config-atlas raw index URL (same block class as the
-  earlier state-hub/feature-control issue)
-- Note: likely interacts with the Gitea→Forgejo host transition
-  (REUSE-WP-0019-T01); if the new Forgejo raw URL scheme fixes it, record that
-  and close here
-- Target: 61/61 publish pass
+**Diagnosis complete — two separate issues, conflated in the original note:**
+
+1. **The 303 itself was not actually a live blocker.** Gitea's raw-URL
+   scheme is `/raw/main/<path>` -> 303 redirect -> `/raw/branch/main/<path>`
+   -> 200. `establish.py`'s `_probe_raw_url` uses `urllib.request.urlopen`,
+   which already follows redirects transparently (verified: HEAD request to
+   the `/raw/main/...` URL resolves to 200 today). Re-running
+   `establish --publish-check` for config-atlas now returns **PASS**. The
+   roster's `publish_check: fail` was stale data from the 2026-06-16 sweep,
+   not a reproducible current failure — corrected in the roster (publish
+   pass now 61/61).
+2. **config-atlas was never actually registered with the production hub.**
+   Diffing `https://reuse.coulomb.social/v1/federated` (60 sources) against
+   the local roster (61 repos) shows config-atlas is the only mismatch —
+   present in `sources.yaml` and locally claimed `hub_registered: true`
+   (from the config-atlas registration commit), but genuinely absent from
+   the hub. Corrected the roster's `hub_registered` to `false` for
+   config-atlas (summary count 61 -> 60) to reflect reality.
+
+**Blocked on a credential I should not obtain informally:** completing the
+hub registration needs `reuse-surface hub register --repo config-atlas
+--url ... REUSE_SURFACE_TOKEN=<write-token>`. No catalog entry exists yet
+in `~/ops-warden/registry/routing/catalog.yaml` for this token (checked via
+`warden route find`) — it isn't a generic OpenBao/Vault lane, it's
+reuse-surface's own hub write credential. **Needs Bernd to either provide
+the token or point at where it's routed.**
+
+- [x] Diagnose the 303 (resolved — not a current blocker, code already follows the redirect)
+- [x] Local publish-check target: 61/61 pass
+- [ ] Complete hub registration for config-atlas (blocked on `REUSE_SURFACE_TOKEN`)
 
 ## Closeout: Coverage Metrics, Docs, SCOPE Update