feat: add emailVerifiedField to identity provider model and update related logic

[chenyme]

Summary

Improve OAuth account linking and authentication UX. OAuth login can now safely link an existing account by normalized email when the provider reports a verified email, while manual account binding remains available for already authenticated users. The login page no longer exposes a separate third-party “register” flow, and the OAuth callback page avoids false “session expired” flashes caused by duplicate React effect execution.

Also improves frontend error presentation so settings and admin operation failures show concrete backend validation messages instead of generic toast text.

Change type

• Bug fix
• Feature
• Documentation
• Refactor
• Configuration / deployment
• Security hardening
• Other

Affected areas

• Frontend / UI
• Backend / API
• Authentication / authorization
• Conversations / streaming
• Files / RAG / extraction
• Model routing / providers
• MCP / tools
• Billing / payments
• Admin console
• Deployment / Docker / configuration
• Documentation

Verification

• cd backend && go test ./...
• cd frontend && pnpm lint
• git diff --check

Screenshots, API examples, or logs

N/A

Configuration, migration, and compatibility notes

Adds email_verified_field to identity provider configuration, defaulting to email_verified. Existing providers continue to work with the default value, and admins can override the field mapping for providers such as Discord.

No deployment configuration changes are required.

OAuth auto-linking only occurs when the provider email is verified. Manual binding is still allowed from an authenticated account and continues to protect against binding an identity already owned by another account.

Documentation

• Documentation is not needed for this change.
• Documentation was updated.
• Documentation still needs to be updated.

Security and privacy

• No secrets, tokens, credentials, local config, or personal data are included.
• User data access remains scoped by authenticated user context unless an admin-only path explicitly requires broader access.
• Security-sensitive behavior was reviewed, including authentication, authorization, provider routing, file processing, billing, and admin APIs where relevant.

Checklist

• I searched existing issues and pull requests.
• Changes are focused and do not include unrelated refactors.
• Tests or static verification were run where practical.
• User-facing behavior, deployment steps, API contracts, or configuration changes are documented.
• Generated artifacts are included only when this project explicitly requires them.
• Caches, build output, .pyc files, .env files, and local storage data are not committed.