feat: add email_verified mapping to SSO attribute configuration

[danielraab]

Add email_verified to the SSO attribute mapping

Summary

The SSO attribute mapping (attribute_mapping on sso_providers) let admins remap
email, name, given_name, family_name, and username, but the verified-email
signal was hardcoded to the standard OIDC email_verified claim. IdPs that expose
verification status under a different claim/attribute name had no way to wire it up,
so those users were unnecessarily pushed through in-app email verification.

This adds email_verified as a configurable key in the mapping, defaulting to
"email_verified" so existing behaviour is unchanged.

Changes

• AttributeMap (internal/sso/provider.go) — new EmailVerified field;
  included in the built-in default map.
• OIDC (internal/sso/oidc.go) — ExtractClaims resolves the verified-email
  claim name from the mapping (falling back to email_verified), marks
  EmailVerifiedProvided when that claim is present, and parses its value via a new
  claimToBool helper that accepts JSON booleans and "true"/"false" strings.
  When the standard claim name is used and absent, it still falls back to the
  library-parsed value.
• SAML (internal/handlers/sso_saml.go) — if the IdP asserts the mapped
  attribute, its value is honoured (strconv.ParseBool); otherwise the existing
  provider-trust behaviour (require_verified_email) applies.
• Schema (internal/database/schema/sso.sql, sso_postgres.sql) —
  attribute_mapping column default now includes "email_verified":"email_verified".

Compatibility

• No migration required — attribute_mapping is a free-form JSON blob (validated
  only for size + well-formed JSON). Existing providers with an older mapping simply
  fall back to the email_verified default in GetAttributeMap.
• Behaviour is identical for any provider that doesn't set the new key.

Notes / follow-ups

• There is no admin UI field for attribute_mapping in SSOSettings.svelte today;
  it's API-only. A UI editor for the mapping could be a separate change.

Testing

• go build ./..., go vet, and gofmt pass. The repo currently has no SSO
  handler/service tests to extend.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[danielraab-tc]

I have read the CLA Document and I hereby sign the CLA

[danielraab]

I have read the CLA Document and I hereby sign the CLA

[stefan-ernst]

Thank you, that change makes sense! Will test my own Entra Tenant in a moment