Resolve Solid/LWS storage context for cache keys and refresh locks instead of individual request URLs #46

Problem

On current main, issuer, authorization-server metadata, and DPoP token caches use request.url; client registrations use the issuer. Two resources in the same Solid/LWS storage therefore repeat discovery or authentication. Simply replacing the URL with its origin or issuer is unsafe: an origin can host several storages, and an issuer can serve unrelated accounts and resource servers.

Proposal — issue only

Design a configurable context/key resolver independently of cache persistence and the component caching design in #29. Keep the core library protocol-agnostic; supply Solid/LWS-aware discovery as an adapter.

• Discover an authoritative storage root/context using the protocol's advertised relationships and storage description, validating trust and membership. The Solid Protocol specifies a storage-description Link relation. Define which deployed Solid/LWS versions and relationships are supported rather than assuming their vocabularies are interchangeable.
• Distinguish resource-to-storage mapping from issuer metadata (issuer), client registration (issuer + client configuration/redirect URI), and credentials (storage/resource audience + issuer + client + account + scope + DPoP binding as applicable).
• Never infer authorization to send credentials from a cached mapping alone. Do not widen a credential audience merely because URLs share a host or issuer; coordinate with feat: allowed-origins credential boundary — don't attach credentials to third-party 401s #22's credential boundary work.
• Specify URL canonicalization, path-segment boundaries, redirects, nested/multiple storages on one origin, cross-origin storage descriptions, mapping expiration and invalidation, account switches, missing/CORS-hidden metadata, and a conservative exact-URL fallback.
• Use the same resolved credential context for token cache keys and Web Lock names, including cross-tab refresh-token rotation. Avoid embedding tokens or other secrets in lock names.
• Keep DPoP proofs request-specific (htu, htm, fresh jti); sharing credential material never means sharing proofs.

Acceptance criteria

1. Requests to two resources in one verified storage reuse appropriate cached material.
2. Distinct storages on the same origin remain isolated, as do clients/accounts using the same issuer.
3. Host-prefix lookalikes, path-prefix lookalikes, redirects, untrusted discovery links, and unknown contexts cannot broaden credential disclosure.
4. Concurrent refreshes across resource URLs and browser tabs consume a rotating refresh token at most once.
5. Discovery failure does not poison caches; invalidation/logout behavior is specified alongside feat: renew the session once when an upgraded request is still rejected (401) #14/feat: definitive session teardown (forget) with a supersession fence #23.

No implementation PR is requested for this issue yet. This also records the storage-scope portion of the older per-issuer cache proposal #11, without adopting issuer-wide credential sharing.

Related persistence work: #45. Configurable storage adapters do not themselves authorize broader credential reuse.