Better handling for mismatch between stored credentials and linked identities

When the user authenticates an identity provider, we store the relevant credential in Firebase for later use. This allows us to still have a GitHub credential available when you refresh the page while logged in, for instance.

In principle, it’s possible for an account to be linked to an identity, but for us to have no credential stored for that identity. There is no known user flow that would currently result in this state, but there have been in the past (particularly when we first started storing credentials).

The current behavior is to simply log the user out if they are missing a stored credential. This worked fine in a single-provider world since logging back in would always generate a new credential which could then be stored.

Currently, though, this behavior could result in a user being locked out of their account, since the missing credential may not be for the primary login identity provider.

Several possible approaches here—could do something robust to try to figure out the best way to get the user to reauthenticate, for instance. Or we could just assume the happy path will always obtain, and send ourselves an error notification if it does not, so we can investigate further.

No files, tests, or entry points are named. Trace the Firebase credential storage and linked-identity authentication flow described in the issue, then establish the chosen reauthentication or error-notification behavior and verify that a missing non-primary credential no longer locks users out.