fix(auth): let the linking rule actually decide, instead of Auth.js refusing first

[kunjhirapara]

Signing in with Google against an account that already exists answers OAuthAccountNotLinked. Every account predating this migration has an email address, so that is every existing user permanently locked out of Google and GitHub sign-in.

The ordering assumption I got wrong

The design was that our signIn callback applies mayLinkToExistingUser and decides. It does run first — @auth/core calls handleAuthorized before handleLoginOrRegister, which I verified when writing it. But approving there turns out not to be sufficient, because handleLoginOrRegister then applies a refusal of its own:

if (userByEmail) {
  if (provider?.allowDangerousEmailAccountLinking) { user = userByEmail; }
  else { throw new OAuthAccountNotLinked("Another account already exists with the same e-mail address"); }
}

Our rule never got to matter. Auth.js had already said no.

Why setting the "dangerous" flag is the safe option here

It is the only way to let the rule decide at all. And the guard that makes it safe already exists — it was built for exactly this:

• The flag is named dangerous because Auth.js cannot tell whether the provider verified the address. On its own it means anyone able to add a victim's address to their own Google or GitHub account inherits the victim's Commit account and its role.
• mayLinkToExistingUser answers precisely that question, refuses unless the provider positively asserts the address is verified, and runs before the linking happens.
• src/auth.config.ts overrides GitHub's userinfo request for the same reason: the stock provider discards the verified flag, and a guess in that argument would defeat the guard entirely.

The two are now a pair, and both ends say so in the code. Removing the signIn callback, or weakening mayLinkToExistingUser, silently turns this flag back into what its name says it is.

Behaviour after this

Provider says the email is verified, and it matches an existing account	Linked, existing user and role preserved
Provider does not assert verification	signIn returns false → AccessDenied, no link
No existing account with that address	New user created as before

Verification

263/263 tests pass, tsc --noEmit clean, production build green. mayLinkToExistingUser and the GitHub verified-email selection both keep their existing test coverage — this PR changes which of the two refusals fires first, not the rule itself.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.