Registering with an uppercase email permanently locks the user out

A user signs up as Jane.DOE@Example.com. Registration returns 201 with tokens -- everything looks like it worked. The very next time they try to log in -- typing the exact same email, just as their keyboard or autofill happened to case it, or normalized to lowercase the way most people type emails out of habit -- login fails with "invalid email or password." To the user this is indistinguishable from a hacked account or a forgotten password. They'll try resetting their password (which won't fix anything, since the password was never wrong), then give up or file a support ticket. This is a silent, permanent account lockout for an unknown fraction of signups, with no error at signup time to warn anyone.

register() stores the email exactly as submitted (after only .strip()), while login() normalizes the submitted email to lowercase before looking the user up. Register with Jane.DOE@Example.com, then log in with jane.doe@example.com (or any different casing) -- login fails with 401 invalid_credentials, even though the password is correct and it is unambiguously the same email address. As a second symptom of the same root cause: registering DUPE@EXAMPLE.COM after dupe@example.com already exists succeeds instead of being rejected as a duplicate -- the "is this email taken" check is case-sensitive too.

curl -s -X POST localhost:5000/api/auth/register -H "Content-Type: application/json"
-d '{"email": "Jane.DOE@Example.com", "password": "strongpassword"}'

201 Created

curl -s -X POST localhost:5000/api/auth/login -H "Content-Type: application/json"
-d '{"email": "jane.doe@example.com", "password": "strongpassword"}'

401 {"error": {"code": "invalid_credentials", ...}} <- same account, same password, locked out

register() computes email as data["email"].strip() -- no .lower() -- while login() computes it as data["email"].strip().lower(). Two call sites that are supposed to treat "the same email" as the same value disagree on normalization. Whichever one is "correct" doesn't matter in isolation -- what matters is that they must agree, and right now they don't. users.email has a unique=True database constraint, which only prevents byte-for-byte duplicate strings -- it does nothing to enforce case-insensitivity, so this has to be handled in application code before the value ever reaches the database.

Look at the one line in register() that computes email from the request payload, and compare it to the equivalent line a few lines down in login(). Both call sites need to agree on the same normalization rule for what counts as "the same email address."