Add OAuth device flow, token introspection, and dynamic client registration

Adds three OAuth surfaces to the OIDC provider so CLIs, terminal agents, and
MCP connectors can authenticate as real users instead of using static API keys.

Device Authorization Grant (RFC 8628):
- OidcDeviceCode model (HMAC device_code, short plaintext user_code, nullable
  user until approval, slow_down polling state), mirroring OidcAuthorizationCode
- POST /oauth/device_authorization issues the code pair + verification URIs
- device_code grant on /oauth/token returns authorization_pending / slow_down /
  access_denied / expired_token, then the standard token triple; single-use
- Authenticated /device approval page, gated by Application#user_allowed?

Token Introspection (RFC 7662):
- POST /oauth/introspect: confidential-caller-authenticated; returns active,
  scope, and the user's groups so resource servers can authorize on membership

Dynamic Client Registration (RFC 7591):
- POST /oauth/register creates public/confidential clients (PKCE required)
- Runtime toggle via a new Setting store + admin switch on the Applications page;
  off by default, env var CLINCH_DCR_ENABLED as bootstrap fallback
- New clients are default-deny (no allowed_groups) until an admin grants access
- RFC 8414 metadata alias at /.well-known/oauth-authorization-server;
  registration_endpoint advertised only while the window is open

Discovery advertises all three grants/endpoints. Seeds add a clinch-cli public
client and a c2a2-introspection confidential client. ADRs in docs/decisions
record the opaque-vs-JWT, device-flow, and DCR-security decisions.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F7cwhwDJp3MJJDoNPVE6zq

docs/decisions/0001-opaque-vs-jwt-access-tokens.md

@@ -0,0 +1,39 @@
+# 0001 — Opaque access tokens (not JWT); introspection for resource servers
+
+**Status:** Accepted · **Date:** 2026-07-19
+
+## Decision
+
+Clinch issues **opaque** access and refresh tokens — random strings stored server-side
+as SHA-256 HMACs (`OidcAccessToken` / `OidcRefreshToken`), not self-contained JWTs. The
+**ID token stays a JWT** (RS256), because it is meant to be read by the client. Resource
+servers that need to validate an access token call the **RFC 7662 introspection endpoint**
+(`POST /oauth/introspect`), which also returns the user's `groups` for authorization.
+
+## Context
+
+There is no universal winner between opaque and JWT access tokens; it is an architecture
+call:
+
+| | Opaque (reference) | JWT (self-contained) |
+|---|---|---|
+| Validation | Resource server calls back (introspect/userinfo) | Offline signature check against JWKS |
+| **Revocation** | **Instant** — the AS holds the state | Valid until expiry unless a blocklist is added (which re-adds state) |
+| Best when | One central IdP, few resource servers, revocation matters | Many resource servers, high throughput, offline verification needed |
+| Token contents | Nothing leaks (just a handle) | Claims readable by any holder |
+
+Clinch is a single self-hosted IdP with a handful of relying parties. It already has
+instant revocation, including refresh-token **family revocation** on reuse. That
+revocation guarantee is a real security property for an IdP, and the introspection
+callback cost is negligible at this scale (and cacheable by the resource server).
+
+## Consequences
+
+- Resource servers (e.g. c2a2) cannot verify tokens offline; they must call
+  `/oauth/introspect` (authenticated as a confidential client) and should briefly cache
+  positive results.
+- Tokens can be revoked immediately (logout, admin action, reuse detection) and stop
+  working at the next introspection — a property JWT access tokens can't offer without
+  reintroducing server state.
+- If we ever need many resource servers with zero-latency offline verification, revisit
+  with RFC 9068 (JWT access token profile) — accepting the loss of instant revocation.