fix(auth): store the MFA enrolment in one transaction and never return database text (#714)

[alex-dembele]

Closes #714

#889 already fixed the lockout in this issue's title: an unfinished enrolment can start over. This PR does what #714 still asked for, plus two defects found on the way. Spec: docs/714_MFA_SETUP_ATOMIC.md.

One transaction. Setup wrote the secret, deleted the old backup codes and inserted the new ones as three statements, so a failure on the last left a new secret with no backup codes. MFARepository.StartMFAEnrolment now does all three in one transaction. The secret goes through an upsert on user_id that only applies to an unverified row of the same tenant, which also closes the race #889 left: two first setups at the same moment used to send the second one into the unique index (400). Codes are bcrypt-hashed before the transaction opens. ReplaceUnverifiedMFASecret lost its only caller and is removed.

No database text in responses. mapAuthError sent any untyped error back as 400 {"error": err.Error()}. It now answers 500 with the generic FR/EN message and logs the real error. This applies to setup and verify; typed errors (validation, not found, conflict, forbidden) answer exactly as before.

Tombstones from before #754. Turning MFA off used to soft-delete the secret. That hidden row still holds the unique user_id, so on master such an account got 400 on every setup. It is now brought back as a fresh, unverified enrolment, still within its own tenant.

Frontend. Only the two guard comments change. The guards stay, for a new reason: each call now voids the previous key, so a double effect could leave an unusable QR code on screen.

Escalated, not fixed. user_id is unique across tenants while every query is per tenant, so a person in two organisations can enrol in only one. Raised as D-066, tracked in #897.

Tests

• Repository, SQLite plus Postgres twins: create, replace N times (one row, last 8 codes), verified refusal, tenant scope, tombstones, rollback when the code insert fails, 10 concurrent first setups. Removing the transaction, the is_verified guard, the upsert or the tombstone clause each makes a test fail (checked by mutation).
• Use case: TestSetupMFA_Success (one store call, 8 scoped bcrypt codes), _NotFound, _Unauthorized, _StoreFailureIsNotAConflict. fix(auth): an unfinished MFA enrolment locks a privileged account out for good — setup answers 400 forever #889's _ReplacesAnUnverifiedSecret and _VerifiedSecretIsKept are kept under those names (owner's call): they are this issue's _ReplacesUnverifiedSecret and _VerifiedConflict.
• HTTP: setup three times → 200 each, one row; forced store failure → 500, generic body, no secret stored.

Verified

go test ./...                                     → 80 packages ok, no FAIL
DATABASE_URL=… go test -race ./internal/application/auth/ ./internal/infrastructure/repository/ ./internal/handler/auth/  → ok ×3
golangci-lint v1.64.8 run --new-from-rev=origin/master (touched packages) → no issues
npx tsc -b --noEmit · eslint on the two .tsx files → clean

Live, branch server on a throwaway Postgres 16:

setup #1/#2/#3 → 200 · mfa_secrets rows 1 · unused codes 8
verify, first QR code → 400 invalid TOTP code · last QR code → 200 · setup again → 409
code insert forced to fail (trigger) → 500 "Something went wrong…" / "Une erreur est survenue…"; secret unchanged, codes 8 → 8
verified tombstone → setup 200 → verify 200, row live and verified

Not done

• The devsecops review in the DoD has not run as a separate pass. I reviewed the diff for tenant scope, logging and the verified-secret path myself, and the owner may want the agent pass before merging.