ci: authenticate the registry upload with DX_HUB_API_KEY

[wittjosiah]

The registry publish 401s at the edge upload: it authenticates with a hub-identity verifiable presentation, and CI holds no HALO identity to produce one ('unauthorized response received before identity was set' in dxos's base-http-client). Seeding an identity per run would accrete a device into its HALO on every release, so the unblock is the edge/hub admin API key.

Changes

• release.yml — pass DX_HUB_API_KEY: ${{ secrets.DX_HUB_API_KEY }} (already set on this repo) to the publish step. The CLI side (dxos branch a66cc24, PR to follow once proven) sends it as X-Admin-Key in place of the VP flow, leaving the identity path untouched when the env is absent.
• release.yml — new optional cli_package dispatch input overriding the pinned DX_CLI_PACKAGE, so a pkg.pr.new branch build can be tested against the real edge before its dxos PR lands.
• debug-registry-auth.yml — the edge probe now also POSTs /registry/upload with X-Admin-Key (status only), answering the one question not observable from these repos: whether the edge honors the admin key on that route.

Verification (CLI side, local)

Against a live local HTTP server capturing headers:

requests : [{"url":"/registry/upload","adminKey":"test-key-123","auth":null}]
checks   : auth-prefetch-skipped=true  admin-key-sent=true  no-vp-header=true

The sandbox cannot reach the real edge (socket close before response), so server acceptance is exactly what the debug probe and the next registry_only dispatch establish.

Test plan after merge

1. Dispatch Debug registry auth → the with X-Admin-Key status per environment tells us if the server honors the key.
2. Dispatch Release with registry_only: true and cli_package=https://pkg.pr.new/dxos/dxos/@dxos/cli-linux-x64@a66cc24 → the full credentialed publish with the branch CLI.
3. If both pass, open the dxos PR for a66cc24 as proven.

---

Generated by Claude Code