Activate descriptor-backed PKCE refresh

[adamcik]

The authorization store and refresh policies are already on main; this PR connects them to the running Web client. Playback authorization is unchanged.

• Prefer stored PKCE authorization over configured bridge credentials.
• Allow bridge fallback when authorization is missing or cleared, but never after PKCE rejection or an unreadable manifest.
• Preserve authorization on transient failures. A permanent PKCE rejection requires reauthorization.
• Reject stale refresh results after logout or reauthorization; persist the transition before installing its access token.
• Keep HTTP retries, response validation, and access-token expiry in the shared OAuth client. Providers handle grant-specific eligibility, requests, and response processing.

Review path

1. backend.py wires the store, PKCE provider, and bridge provider into SpotifyAccessTokenSource.
2. oauth/source.py owns the refresh transaction shown below. The network request runs without the store lock. Selecting a provider is the only opportunity for fallback; a failed exchange does not try another grant.
3. oauth/providers.py contains the grant differences: PKCE retains or rotates its refresh token; the bridge uses configured credentials and ignores refresh tokens in its response. web.py installs the access token only after the source returns successfully.

flowchart TD
    A[Load authorization snapshot] --> B[Select provider]
    B -->|PKCE authorized| C[PKCE request]
    B -->|Missing, cleared, or bridge state| D[Bridge request if configured]
    B -->|PKCE rejected or no provider| X[Stop without an exchange]
    C --> E[Exchange and validate response]
    D --> E
    E --> F[Provider processes response]
    F -->|Transient failure| G[Preserve state; report failure]
    F -->|Success or permanent rejection| H{Snapshot still current?}
    H -->|No| I[Discard stale result]
    H -->|Yes| J[Persist proposed state]
    J -->|Success| K[Install access token]
    J -->|Permanent rejection| L[Report rejection]

Loading

Compatibility caveat: every refresh retries a permanently rejected bridge configuration, even if its credentials are unchanged. This allows corrected configuration to recover without clearing the manifest. A separate credential-fingerprint follow-up will distinguish changed credentials from repeated attempts with the rejected pair.

Tests exercise provider precedence, token rotation, transient and permanent failures, and logout/reauthorization during an in-flight refresh. #450 documents the architecture; #451 handles separate playback authorization.