OAuth client registry moves from config.yaml to a cratestack model

## Directive (owner, 2026-08-25, verbatim)

> Clients are controlled by config file as of now. That too shall be expanded to Cratestack's model and controlled. Only difference, models enabled via config.yaml can only be disabled from the UI, not deactivated.

## Shape

`oauth2.clients` (config-file registry consumed by the OpStore client lookup) becomes a cratestack model (`OauthClient` or similar) in `authz.cstack`, DB-backed and UI-manageable, with config.yaml-declared clients seeded/merged at startup.

## Open questions for the owner (flagged, not guessed — directive arrived mid-sleep)

1. **Disabled vs deactivated**: what is the intended semantic difference? Reading: config-sourced clients may be turned OFF from the UI (soft, reversible) but never removed/deactivated (hard) — i.e. config remains the source of their existence, the DB only carries an enabled bit. Confirm.
2. Does DB state override config on restart (config re-seed must not resurrect a UI-disabled client)?
3. Which `@@allow` posture? Precedent: `User` and `Session` carry NO allow clauses (fail-closed, no generic surface) — but a UI needs SOME surface, so this model needs real policies + new `Permission` variants + `rpc_authorize` entries + `schema_policy_sync_tests` regen, unlike ADR-0024's User.
4. Client secrets/keys: if confidential clients ever land, storage must follow the ADR-0024 sealing pattern, not plaintext columns.

## Interactions

- ADR-0024 (users/federated identities) establishes the fail-closed cstack-model pattern this should follow.
- The device-grant client registration for opencode (Phase-4 cutover) would land in this model instead of another config edit.
- Prod config note: today every client change is an ai-helm-values PR (5-copy problem, see prod-config-overrides memory) — this issue removes that pain, which is likely its real motivation.

## AI Usage Declaration
Filed by Claude during the overnight run to bank the directive verbatim with its ambiguities explicit; no design decisions taken. Human owner must answer the open questions before implementation.

Source of truth: owner directive quoted above; ADR-0024.

Start by reading ADR-0024, then inspect the oauth2.clients registry in config.yaml, the OpStore client lookup, and the authz.cstack model patterns. Resolve the owner’s open questions before implementation, then trace the policy work through Permission variants, rpc_authorize entries, and schema_policy_sync_tests. Done means the agreed model behavior and policy coverage are implemented and verified.

由索引模型根據 Issue 內容生成。