/auth/providers endpoint enables email enumeration; add rate limiting

[bpowers]

Description

The /auth/providers endpoint returns whether an email address is registered and which authentication providers are linked to it. This allows an attacker to enumerate valid email addresses by querying the endpoint with candidate addresses and observing the response.

This is a pre-existing concern inherited from Firebase's fetchSignInMethodsForEmail API, but now that authentication has moved server-side, mitigation is feasible.

Why it matters

• Security: Email enumeration is a recognized vulnerability (OWASP). Attackers can use it to build lists of valid accounts for credential stuffing, phishing, or social engineering.
• Privacy: Users may not want their registration status to be publicly discoverable.

Component(s) affected

• src/server -- specifically the /auth/providers route handler

Possible approaches

1. Rate limiting: Add per-IP and/or per-session rate limiting on the /auth/providers endpoint (e.g., via express-rate-limit). This is the most straightforward mitigation and does not require changing the endpoint's behavior.
2. Uniform responses: Always return a success response regardless of whether the email exists, and handle provider selection client-side after the user attempts to authenticate. This is more secure but requires client-side changes.
3. CAPTCHA/proof-of-work: Require a challenge before responding, raising the cost of enumeration.

Approach 1 (rate limiting) is likely the best starting point as it is low-effort and does not change the user experience.

Context

Identified during review of the server-side auth migration (branch server-side-auth). The endpoint is necessary for the login flow to determine which provider to use, but it currently has no throttling.