[Ticket]: cut opencode over to the device grant and lightbridge-ss over to /authorize (blocks on #426)

### Type

Operational task

### Summary

We need to actually move opencode's CLI and the self-service dashboard (`lightbridge-ss`) off
their current auth paths onto `authz-idp`'s new flows, each behind its own gate, because standing
up `/authorize` and the device grant (#423-#426) does not by itself retire token-exchange for
anyone — clients have to be repointed.

Expected result:

> opencode's CLI authenticates via the device grant against `auth.ai.camer.digital` instead of
> Keycloak directly (`auth.verif.fyi`); `lightbridge-ss` authenticates via `/authorize` + PKCE
> instead of token-exchange; each cutover is independently verified and independently revertible.

### Intent

This is the ADR-0019/owner-instruction payoff: "remove token-exchange from most of our clients"
only happens when clients actually move. Per this repo's "hard cutover, not smooth transitions"
house convention, each client's cutover should be a real switch, not a long-lived dual-path — but
per the same convention's own caveat, a risky change is verified hard and cut over, not hidden
behind a flag; this ticket's gates are about sequencing safe verification per client, not building
parallel/back-compat paths.

`governance-auth` (in `lightbridge-governance`, a sibling repo) is explicitly **not** included here
even though ADR-0012's Context discusses it at length: ADR-0012 Decision 8 and its own Alternatives
section already established that `governance-auth` authenticates directly against Keycloak, not
through this service's token-exchange grant, so it is not currently a client of this service to cut
over from. Whether `governance-auth` should *adopt* the device grant this service now serves is an
open question ADR-0012 left unresolved (its own "Neutral/follow-ups") — out of scope here, not
silently dropped.

### Source of truth (links)

- https://github.com/ADORSYS-GIS/lightbridge-authz/pull/422 — ADR-0019, Decision 3 (client-to-flow
assignment: device grant for CLIs, authorization-code for browser clients, token-exchange stays
for `lightbridge-mcp`)
- #426 — discovery must advertise the real endpoints before any client can be pointed at them
(hard dependency)
- `ai-helm/charts/librechat-opencode-wellknown/values.yaml` — opencode's current Keycloak-direct
config (`issuer: https://auth.verif.fyi/realms/camer-digital`, `authFlow: device_code`)
- #337 — the epic this ticket re-scopes (its own Phase 4 covers the opencode leg; this ticket adds
the dashboard leg ADR-0019 introduces)

### Current Behavior

opencode's chart sets `issuer: https://auth.verif.fyi/realms/camer-digital`, `clientId:
opencode-cli`, `authFlow: device_code` — authenticating directly against Keycloak, not through
`authz-idp`. `lightbridge-ss` is registered in `oauth2.clients` as a token-exchange client
(ADR-0011 Decision 5) and presumably obtains its `subject_token` through some other existing
mechanism before exchanging it (the exact current mechanism should be confirmed against
`lightbridge-ss`'s own repo/config as part of this ticket, not assumed here).

### Expected Behavior

Two independent sub-cutovers, each with its own verification gate — do not couple them:

**5a. opencode → device grant via `authz-idp`**
- Change `issuer` to `https://auth.ai.camer.digital` in
`ai-helm/charts/librechat-opencode-wellknown/values.yaml`, leaving `authFlow: device_code`,
`clientId`, and `scopes` unchanged (per ADR-0012's own stated goal — "everything else on the
client side... stays as-is").
- Register `opencode-cli` in `authz-idp`'s `oauth2.clients` config with the `device_code` grant
type.
- Verify end-to-end against a real opencode CLI session before merging the `ai-helm` change to
prod.

**5b. `lightbridge-ss` → `/authorize` + PKCE**
- Migrate the dashboard's client-side auth integration from whatever currently drives its
`subject_token` acquisition to a standard authorization-code + PKCE redirect against `authz-idp`.
- Confirm `lightbridge-ss`'s registered `redirect_uris` entry (from #425) matches its real deployed
callback URL exactly, in every environment (dev/staging/prod) — a registry that only matches prod
silently breaks every other environment's login.
- Verify a full login round-trip in each environment before considering that environment cut over.

**Both**: once verified, `oauth2.clients` config no longer grants either client the
`urn:ietf:params:oauth:grant-type:token-exchange` grant type (hard cutover, not a dual-path), and
the change is independently revertible per client (a config revert, not a code rollback).

### Acceptance Criteria

- [ ] Given the `ai-helm` `issuer` change is deployed, when an opencode CLI user authenticates, then
they complete device pairing against `auth.ai.camer.digital` and obtain a working token —
verified against a real session, not just a config diff review.
- [ ] Given `lightbridge-ss`'s auth integration is migrated, when a dashboard user logs in, then
they complete the `/authorize` + PKCE round-trip and land authenticated — verified in every
deployed environment, not just one.
- [ ] Given either client is fully cut over, when its `oauth2.clients` entry is inspected, then it
no longer lists the token-exchange grant type.
- [ ] Each sub-cutover (5a, 5b) is independently revertible via a config-only change.
- [ ] Verification evidence is provided for both sub-cutovers separately.

### Out of Scope

- `governance-auth` — not a client of this service today (ADR-0012 Decision 8); whether it adopts
the device grant is a separate, unresolved question, not covered here.
- Replacing `lightbridge-keycloak-spi` — unaffected by any of this per ADR-0012's own scoping;
it only becomes redundant for clients that move to lightbridge-issued tokens, and no ticket here
removes it.
- Any change to `lightbridge-mcp`'s registration — it stays on token-exchange per ADR-0019 Decision
3, explicitly not part of "most clients."

### Technical Context

- `ai-helm/charts/librechat-opencode-wellknown/values.yaml` and its README (the
`authFlow: device_code` note)
- `crates/lightbridge-authz-core/src/config/mod.rs` — `oauth2.clients` config, where both client
registrations live
- `lightbridge-ss`'s own repo (not in this workspace) — its current auth integration code, to be
located and confirmed before scoping the actual migration work precisely

### Risks

| Risk | Mitigation |
|---|---|
| opencode users mid-session during the `issuer` cutover | Coordinate the `ai-helm` deploy timing; device-grant sessions are short-lived by design, so a brief overlap window is low-risk, but state the plan explicitly in the PR |
| `redirect_uris` mismatch across environments silently breaking non-prod logins | Explicit per-environment verification, not just a prod smoke test |
| Reverting one client's cutover after the other already removed token-exchange from shared config | Keep each client's `oauth2.clients` entry and grant-type list independently editable/revertible; do not merge them into one shared config block |

### Test Plan

- Manual end-to-end verification: real opencode CLI device-grant login against
`auth.ai.camer.digital`
- Manual end-to-end verification: real `lightbridge-ss` login in each deployed environment
- `just it-servers` (regression check that nothing else on the JWT/authn surface broke)
- `just all-checks`