Storage for refresh tokens issued by token exchange #6895

Part of #6886. Needed by #6896 and #6897.

Problem: session and schedule refresh tokens need state that fosite's refresh-token storage cannot hold: one owner per key, keys never reused, every token of a user findable, and several records changed atomically.

Change: a new storage interface (memory and Redis) for refresh tokens issued by token exchange. Per row:

• namespace and session key (unique per namespace);
• grant type (session or schedule), local user, owner (sub_id), source token jti;
• allowed targets (audience, resource) recorded at issuance, so a later configuration change never widens an existing token (RFC 9700 §4.14.2);
• hard expiry; parent row (a run's session points at its schedule);
• revocation status and reason; a revoked key becomes a tombstone.

Plus: an index from user to rows; atomic updates across several rows; revoke by key (not only by a held token), client-authenticated, a client revoking only its own keys. Revoking a schedule row revokes its children. These rows are stored apart from ordinary refresh tokens, so the refresh-token grant can never redeem them.

Acceptance: concurrency tests for create, replace and revoke on one key; a revoked key cannot be reused; revoke by key succeeds while the caller holds a superseded token.