Keyring for token_encryption_key (rotation without a re-seal window)

Owner (2026-08-25), on ADR-0024's single sealing key: *"yes for now but we quickly need a better solution."*

Current posture: one `oauth2.relying_party.token_encryption_key`; rotating it makes every stored `federated_identities.token_envelope` unopenable until each user's next login re-seals (open-failure == credential absent, fail-closed, never an error).

Target: a keyring — `keys: [{id, key}]` + `active_key_id`, envelope gains a key-id (the `v1.` version prefix exists for exactly this evolution), seal under active, open under any listed. ~1 column + ~40 lines per the ADR-0024 planning estimate. Becomes worth it the moment any consumer depends on continuous availability of stored refresh tokens (ADR-0024 follow-up 4).

## AI Usage Declaration
Filed by Claude to bank the owner's directive; design sketch from the ADR-0024 planning notes, unreviewed.

Source of truth: ADR-0024 (Open Question 2 + Consequences), owner statement above.