Silent authentication loops forever when the OIDC provider no longer knows the stored dynamic client

When a Solid OIDC provider drops a browser's dynamically-registered client (for example, the provider kept client registrations in memory and restarted), the browser's stored clientId is no longer known to the provider. On session restore, silentlyAuthenticate redirects to the authorization endpoint with the stale clientId and prompt=none.

The provider cannot redirect the error back to the app (it cannot validate the redirect_uri of an unknown client), so it returns a non-redirectable "unknown client" error page (e.g. Community Solid Server returns HTTP 400 E0003 Unknown client). Because KEY_CURRENT_URL is only cleared after a successful silent auth, the next page load re-attempts silent auth with the same rejected clientId — looping indefinitely.

Impact

• Affected users see permanently broken sessions/pods. Clearing localStorage on the app origin does not help, because the stale registration lives on the pod subdomain origin.
• The retry storms add load to the provider. Observed in production against Community Solid Server (solidcommunity.net), where it surfaced as rate-limiting (429s).

Environment

• @inrupt/solid-client-authn-browser v5.0.0
• Any Solid-OIDC provider using dynamic client registration that can lose registrations (e.g. Community Solid Server with in-memory OIDC adapter storage).

Steps to reproduce

1. Log in to an app that uses dynamic client registration against a CSS instance; the session is restored across reloads via silent auth.
2. Cause the provider to forget the dynamic client (e.g. restart a CSS instance whose OIDC adapter storage is in-memory).
3. Reload the app: silent auth redirects to the provider, gets 400 Unknown client, and on returning to the app re-attempts with the same clientId. The session never recovers.

Expected

On an unknown/invalid client during silent authentication, the library should discard the stored client registration and re-register instead of looping.

Proposed fix

Detect an incomplete previous silent-auth attempt (a KEY_CURRENT_URL still set on re-entry) and discard the stored client registration so the next login re-registers. PR to follow.

Start by tracing silentlyAuthenticate and the handling of KEY_CURRENT_URL during session restore. Reproduce the lost dynamic client scenario against a provider that returns an unknown-client error, then verify that the stored registration is discarded and the next login re-registers instead of repeating silent authentication indefinitely.