fix(auth): let an unfinished MFA enrolment start over (#889)

[alex-dembele]

Closes #889

A member whose role requires MFA and whose enrolment was ever left unfinished (tab closed, or the 15-minute enrolment token expired) could never sign in again.

SetupMFAUseCase refused only a verified secret, then always inserted a new row. The unverified row from the earlier attempt made that insert fail on the unique mfa_secrets.user_id, so /auth/mfa/setup answered 400 on every later attempt, and every sign-in landed on that broken enrolment.

What changes

• Unverified secret: it is now replaced in place by one conditional UPDATE … WHERE user_id AND tenant_id AND is_verified = false, in the new MFARepository.ReplaceUnverifiedMFASecret. If a verification lands at the same moment, the update touches nothing and setup answers 409, as it always did for a verified secret.
• Replay state: last_totp_step and last_used_at belonged to the abandoned key, so they are reset explicitly rather than through a Save, which security(auth): a TOTP code can be replayed within its validity window #849's contract forbids.
• Verified secret: still refused with 409, and never touched.

Verification

Run on this branch plus #888's one-file fix, because master does not compile until #888 is merged (#886), with a real Postgres:

go build ./... && go vet ./... && DATABASE_URL=… go test ./... -race → exit 0, 80 packages ok, 0 FAIL

New tests:

• TestSetupMFA_ReplacesAnUnverifiedSecret and TestSetupMFA_VerifiedSecretIsKept, with a mock that enforces the unique user_id. The old mock overwrote on insert, which is why this never showed up. Before the fix, the first test failed with duplicated key not allowed.
• TestGormMFARepository_ReplaceUnverifiedMFASecret, on sqlite and on Postgres. It checks tenant scoping, the reset of the replay step, and that a verified secret is left untouched.

Live, reproducing the issue:

1. An invited admin, under a 0-day grace policy, starts enrolment at 12:18 (POST /auth/mfa/setup → 200).
2. The token expires.
3. Signing in again: before this change, setup answered 400. With it, setup answers 200 with a new key, the code from that key answers 200, and the user lands on the dashboard.

Merge order

After #888: CI cannot build the backend until it is in.