Malibu "Open browser wallet" fails with HTTP 404 — allow payout-address registration while payout pipeline is disabled

[Augustas11]

Symptom

Malibu Dashboard → Change wallet → "Open browser wallet" fails immediately with:

Registration failed (HTTP 404).

Reported by an external provider (mp-1962…, Malibu 1.8.88) on 2026-08-08. The browser/signer never opens — the flow dies on its first step.

Root cause (live-verified 2026-08-08)

1. "Open browser wallet" shells to the embedded CLI: payout-address challenge → GET /providers/{id}/payout-address/challenge on the coordinator (PayoutWalletFlow.fetchChallenge).
2. The coordinator only mounts the SPEC-016 §3.3 payout-address routes when payout.enabled=true: setupPayout returns a nil handler on the disabled path (cmd/coordinator/main.go — "payout pipeline disabled (payout.enabled=false); schema applied, handlers idle"), so /providers/{id}/payout-address* is never registered and 404s.
3. Production had payout.enabled=true from 2026-08-03 → 2026-08-05 (journal: "payout pipeline enabled"), during which 3 providers registered wallets successfully. The pipeline was deliberately disabled on 2026-08-07 (overlay backup bak-payout-disable-20260807T064758); every coordinator start since logs the disabled line. From that moment, every Change-wallet attempt from any provider returns HTTP 404.
4. The CLI maps the bare 404 through PayoutAddressClient.userMessage default arm → "Registration failed (HTTP 404)." which Malibu surfaces verbatim.

Existing registrations in provider_payout_addresses are intact and unaffected — only new registrations/changes are blocked.

Requested fix

Decouple payout-address registration from the payout execution pipeline so providers can register/change their payout wallet even while payout.enabled=false:

• Mount the two provider-token §3.3 routes (GET /providers/{id}/payout-address/challenge, POST /providers/{id}/payout-address) whenever the registration prerequisites are configured (payout.security.hot_wallet_address present), regardless of payout.enabled.
• Registration-only mode must NOT start the runner, load the signer/KEK, open RPC connections, or acquire the payout lease — no chain operations. Admin routes (/admin/payout/*) and the /providers/{id}/payouts read endpoint stay behind payout.enabled=true.
• Cooling-off, EIP-712 verification, denylist, pause-registration flag, and audit/alert emission behave identically in both modes.
• SPEC-016 currently treats payout.enabled as a singleton master switch, so this needs a SPEC amendment (registration-only carve-out) bundled with the IMPL in one PR per repo convention.

Secondary (client UX)

Malibu shows the Change-wallet button and a raw Registration failed (HTTP 404). while the server feature is off. Map the 404 to friendlier copy (e.g. "Wallet changes are temporarily unavailable — try again later") and/or hide/disable the flow when the challenge endpoint is absent.

Evidence

• curl https://coordinator.streamvc.live/providers/mp-test/payout-address/challenge → 404 (healthz 200; nginx /providers/ proxy to :8444 confirmed correct)
• Pearl journal: "payout pipeline enabled" through Aug 5 19:44Z; "payout pipeline disabled (payout.enabled=false); schema applied, handlers idle" from Aug 7 13:53Z onward
• Live overlay /etc/macprovider/coordinator.pearl-overlays.yaml: payout.enabled: false

[Augustas11]

Fixed in #955 (merged as d3f1a13).

Code: registration-only mode mounts §3.3 challenge/register + §6.4.1 pause/resume when payout.security.hot_wallet_address is set, even with payout.enabled=false. Execution pipeline stays gated.

Pearl apply (still required for live 404): set the final production hot-wallet pin in /etc/macprovider/coordinator.pearl-overlays.yaml while keeping payout.enabled: false, restart coordinator, confirm journal payout registration-only enabled and challenge returns 401 not 404. See dist/payout-runbook.md §0.