auth: Microsoft SSO does not issue session when emailVerificationRequired=true

Describe the bug

Signing up with the entraid (Microsoft) provider never returns a session when emailVerificationRequired is true. The user row gets created but sign-in doesn't complete. Google works fine with the same setup.

The cause looks like providers/entraid.go reading email_verified from https://graph.microsoft.com/oidc/userinfo. That endpoint doesn't return that claim — Microsoft's docs list the full response as sub, name, family_name, given_name, picture, email and say it can't be customised. So the Go zero value (false) is used every time and IsVerified() is never true.

To Reproduce

1. auth 0.51.0, entraid enabled with tenant = 'common', emailVerificationRequired = true, disableNewUsers = false
2. Go to /v1/signup/provider/entraid?redirectTo=...&codeChallenge=...
3. Sign in with a Microsoft account that has no existing user
4. Account is created with email_verified = false, a verification email is sent, no session is issued

Second case, existing user:

1. Create a user with the same email by another method (magic link)
2. Run the Microsoft flow again
3. Log shows WARN "user is unverified", sign-in is refused — the account can never be linked

Setting emailVerificationRequired = false makes both work. /v1/token/exchange returns 200 and the session refreshes normally.

Expected behavior

Signed in immediately after the provider callback, like Google, and emailVerified = true

Screenshots

N/A — backend, logs included above.

Desktop (please complete the following information):

• OS: macOS
• Browser: Chrome
• Version: N/A (reproduces server-side)

Additional context

Looks like it changed in ec8dab3f2cf46e1131ddaf893d56c37aa00380b2 (#4162, "strict use of email verified with oauth2 providers"), released in 0.49.1. Before that, entraid.go used EmailVerified: userProfile.Email != "", so both cases worked. 0.49.0 doesn't show the problem.

The test case "missing email_verified defaults to false (safe)" in providers/entraid_internal_test.go describes the behaviour, but for Microsoft that seems to be the only branch reachable.

Might need xms_edov from the ID token instead — GHSA-6g38-8j4p-j3pr mentions it isn't used anywhere in the codebase.

Tested with a personal Microsoft account (outlook.de) and a microsoft work email.