Story-2877: Settings → Channels — connect/disconnect a channel + binding status

RFD-AGT-013 (T2c-a, acceptance UAT M-01) gives every counsel a self-service surface to manage their own channel bindings: Settings → Channels (/settings/firm/channels). A counsel mints a single-use 10-minute enrollment code, sends it to Mira from their own WhatsApp, watches the page flip to the bound state on its own, sees the binding lifecycle status (active / needs_reattestation / revoked) rendered from API state, and disconnects (unbinds) behind a confirm dialog. The API is pramaan-functions Story-2848 (merged #788) — enrollment ceremony, own-bindings list, and self-service unbind, all scoped to the caller (no settings:write needed).

Connect → code on screen → send it on WhatsApp → page confirms automatically → bound card with masked number → Disconnect → confirm → instantly refused on the channel.

What changed, layer by layer

The enrollment ceremony (UAT M-01)

1. Generate. Connect WhatsApp → POST /app/channels/enrollment-codes → the plaintext code is shown exactly once (the backend stores only its SHA-256 hash) with a live 10-minute countdown and a copy button. Expired → Get a new code.
2. Send. The counsel sends the code to Mira from the WhatsApp number they want to bind. The page polls GET /app/channels/bindings every 4s while a code is outstanding; polling stops by itself once a binding lands.
3. Bound. The moment the ingress worker consumes the code, the page toasts “WhatsApp connected — •••1234 is now linked to your account” and shows the bound card. Only the API's masked subject (•••1234) is ever rendered — the full number never crosses the wire.

Disconnect = unbind, with a confirm and optimistic cache

Disconnect opens an AlertDialog naming the masked subject and the consequences (channel refusal + dead document links). Confirming fires DELETE /app/channels/bindings/{id} through optimisticCollectionPatch: the cached binding flips to revoked instantly, rolls back + error-toasts on failure, and reconciles on settle — per the optimistic-writes doctrine.

Binding status is rendered from API state

These are the two statuses the current contract (Story-2848) ships; dates render locale-aware via next-intl useFormatter (Hindi UI gets Hindi month names).

Scope boundaries (TICKET-MAP v2)

• Own bindings only — the firm-wide admin register + metadata-only activity UI is T2m-b (API in flight under Story-2879); the generated firm-binding hooks are ready for it.
• No channel ingress, no sender, no re-attestation flow — those are functions-side tickets. No new design system: the page composes SettingsPageHeader, StatusBadge, Button/PrimaryButton, AlertDialog, and catalog card chrome only.

Test evidence

• tests/unit/channels-page.test.tsx — 9 tests: bound-state render (masked subject + status), disconnect confirm dialog → unbind → cache flips revoked → success toast, unbind failure → cache rolls back + error toast, enrollment happy path (empty state → code issued → code card with steps), auto-confirm when the binding appears (toast + code hidden), enrollment polling option (4s while a code is out, stops once bound), issue failure toast, load-failure inline error, revoked history rows with reason and no actions. tests/unit/channels-bindings-route.test.ts — 2 tests: non-UUID bindingId rejected 422 against the generated path contract (HR-21), valid UUID forwarded with upstream headers.
• pnpm lint clean · pnpm typecheck clean · pnpm test green · pnpm check:routes fresh.
• Token scan (no hex/rgb/hsl in new source) and hardcoded-copy scan — both clean; every new string exists in en + hi.