Report the Posit AI Pass account email while setup is pending

[wch]

This PR makes two changes to how the Posit AI Pass provider fetches its model list:

1. While the account's setup is pending, the provider looks up the signed-in account's email and reports it alongside the pending status, so that host apps can add it to posit.ai's setup link (/setup?email=...) and posit.ai can show "Wrong Account" when the browser is signed in as someone else.
2. The provider's cached model list and status now belong to the exact access token that produced them, so that after an account switch or sign-out the app never shows the previous account's models or status.

The email closes a gap in setup: when a user signs in to Posit Assistant as one account while their browser is signed in to posit.ai as another, "Complete setup" finishes setup for the browser's account, and the Assistant's account stays pending. posit.ai now accepts an expected email on its pages (posit-hosted/prism-ui#315); this PR supplies it.

The lookup is off unless the host app supplies a list of candidate login hosts; the Posit Assistant wiring comes in a separate PR. The provider sends the access token only to a host that provably issued it. It checks the token's signature against each candidate host's published public keys and uses the first host whose keys match. It then asks that host for the current user, and accepts the email only if the returned user ID matches the token's.

If anything goes wrong, the provider reports pending status without an email, and the setup link works as it does today. That covers no candidate hosts, an http:// or malformed host, a signature that no host's keys verify, a failed key or user lookup, a redirect to the login page, and a lookup that takes longer than 5 seconds. Failed lookups retry on the next model-list refresh; a successful lookup is reused for the same token and hosts, even across cache clears. The token, the email, and the user response are never logged.

A model-list response that finishes after a sign-out, token change, or cache clear is now discarded instead of overwriting newer state. The cost is one extra model-list request each time the access token refreshes.

Part of posit-dev/assistant#2560. Related to posit-hosted/prism-ui#293

Changes

• Provider registration accepts an optional getter of candidate login hosts (getPositAiAuthHostCandidates on the registration config, or a fifth argument to registerPositAiProvider). Hosts can be bare (login.posit.cloud) or https:// URLs. Without it, behavior is unchanged apart from the token-keyed cache.
• The pending status can carry accountEmail. It appears only with agreement_pending, and only when the lookup succeeded.
• A new or missing access token clears the cached model list and status. Previously, the cache was served regardless of which token filled it, and signing out cleared only the status.

Design decisions

• Signature check instead of the issuer claim. The token's issuer claim is lucid:services:lucid-auth, which names no host. Staging and production publish the same key ID with different keys, so verifying the signature is what tells them apart. It also works for tokens stored before an auth-host edit, without persisting anything new.
• Ordered candidates instead of one host. Positron's sign-in and Posit Assistant's configuration can disagree about the login host on older Positron versions. Using the first candidate that verifies the token covers both without version checks.
• Keyed on the full token, not the user ID. The user ID claim can't be trusted before the signature check, and user IDs can repeat across environments, so a claim-based key could hand one account's email to another.

Not included

• Supplying the candidate hosts from Posit Assistant (Node and Positron), and showing the email in the setup banner and configuration overlay. Those land in the Posit Assistant repo.