fix(auth): keep the address the user registered with, and let it sign them in (E9.5 S3)

Two halves of one rule: the address someone typed is theirs to keep, and it must be
the one that gets them back in.

A plus-tagged or dotted Gmail is often a deliberate choice -- registering as
me+siftlode@gmail.com is how you find out later which site leaked your address. The
Google callback overwrote it with the account's primary, which can never contain a
'+', so the tag vanished on the first Google sign-in and, because sign-in matched the
stored address, took their chosen address with it. The rewrite line is older than
this epic, but S3 made it reachable here by matching adoption across spellings. It
now runs only when the mailbox GENUINELY changed, and lives in a named helper rather
than inline, so the rule has one home.

The three lookups that resolve a typed address -- password login, password reset,
verify resend -- go through find_user_by_email: exact spelling first, then the unique
canonical candidate, and None when several accounts share a mailbox rather than
guessing which one a password should open. Reset and resend previously answered a
different spelling with silence (they reply uniformly by design), which was a dead end
with no way out. Their mail now goes to the address on the account, never the one
typed into the form.

backend/app/auth.py

@@ -92,6 +92,36 @@ def is_allowed(db: Session, email: str) -> bool:
     return email in settings.allowed_email_set or email in settings.admin_email_set
 
 
+def find_user_by_email(db: Session, email: str) -> User | None:
+    """The account someone means when they type an address at sign-in, password-reset or
+    verify-resend. None when there isn't exactly one answer.
+
+    Exact spelling wins. Failing that, the address is resolved to its mailbox
+    (utils.canonical_email) — so a password chosen at registration still works when the person types
+    another spelling of their own Gmail, and so the three flows that look an account up by typed
+    address stop being dead ends. Before this, requesting a reset for `xy@gmail.com` on an account
+    registered as `x.y@gmail.com` issued nothing and said nothing: the endpoint answers uniformly by
+    design, so the user got silence and no way in.
+
+    SEVERAL canonical candidates return None rather than a guess. That case is real — prod carries two
+    accounts for one mailbox — and picking one of them for a password sign-in would hand someone the
+    wrong account. The callers all treat None as "no such account", which is the uniform,
+    non-enumerating answer they already gave.
+    """
+    if not email:
+        return None
+    email = email.strip().lower()
+    exact = db.execute(select(User).where(User.email == email)).scalar_one_or_none()
+    if exact is not None:
+        return exact
+    candidates = (
+        db.execute(select(User).where(User.email_canonical == canonical_email(email)))
+        .scalars()
+        .all()
+    )
+    return candidates[0] if len(candidates) == 1 else None
+
+
 def get_or_create_demo_user(db: Session) -> User:
     """The one shared demo user, created on first use. No OAuth token / YouTube scope, so
     has_read_scope/has_write_scope are False and every YouTube-touching path is closed to it."""