feat: use browser locale and optional cookie persistence

[chenyme]

Summary

Improve authentication and localization behavior.

OAuth login now supports safer same-email account linking by using normalized provider email and the provider’s configured email verification field. Third-party login no longer exposes a separate “register” UI, because OIDC/OAuth providers do not have a distinct registration step in the frontend. The OAuth callback page also avoids false “session expired” flashes caused by duplicate client-side effect execution.

The frontend now shows clearer backend validation errors in toast messages, and first-time visitors without a saved language preference fall back to the browser language before any explicit user or account locale is applied.

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 field, and admins can override it for providers such as Discord.

OAuth auto-linking only occurs when the provider email is verified. Manual binding remains available for authenticated users and still prevents binding identities already owned by another account.

No deployment configuration changes are required.

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.