Support OAuth allowed domains for self-hosted installs

Hi! Opening this as an issue first before doing another PR/rebase, as suggested in #428.

Use case

For self-hosted OpenPanel deployments, it would be useful to enable OAuth login while restricting access to members of a company domain / Google Workspace domain.

A common setup is:

• OpenPanel is self-hosted and reachable on a public URL
• Google OAuth is enabled for convenience
• public registration is disabled with ALLOW_REGISTRATION=false
• only users from an approved company domain should be able to sign in or create accounts through OAuth

At the moment, enabling OAuth does not provide a built-in domain allowlist, so operators need to rely on provider-side configuration or external controls. For Google OAuth, Workspace/internal setup is not always enough by itself for self-hosted deployments, and app-side enforcement would make the behavior clearer.

Proposed behavior

Add optional OAuth domain allowlisting:

• when no allowlist is configured, keep the current behavior unchanged
• when configured, reject OAuth callback users whose verified email domain is not allowed
• for Google, validate email_verified, the email domain, and ideally the Google ID token hosted-domain claim (hd) for Workspace accounts
• matching-domain OAuth users can sign in
• matching-domain OAuth users can sign up even when ALLOW_REGISTRATION=false
• non-matching users cannot sign in or create accounts through OAuth

Possible configuration

Generic option:

OAUTH_ALLOWED_DOMAINS=example.com,example.org

Optionally, provider-specific configuration could also be supported:

GOOGLE_ALLOWED_DOMAINS=example.com

Questions before implementation

• Would you prefer a single generic OAUTH_ALLOWED_DOMAINS option, provider-specific options like GOOGLE_ALLOWED_DOMAINS, or both?
• For Google, should a configured domain allowlist require the hd claim to match, or should verified email domain be enough?
• Should matching-domain OAuth be allowed to create users when ALLOW_REGISTRATION=false, or should the allowlist only restrict login for users that already exist?

Happy to open a fresh PR if this direction makes sense.

Start by locating the OAuth callback and configuration entry points, then determine how verified email domains, Google hosted-domain claims, and ALLOW_REGISTRATION are currently handled. Resolve the generic versus provider-specific configuration and signup behavior questions before implementing; done means matching users can authenticate as specified while non-matching users are rejected and existing behavior is unchanged without an allowlist.