Fix stale 2FA used-code records blocking valid authentication

[sgiehl]

Summary

This PR fixes 2FA code reuse handling when an old twofa_codes_used_* record already exists in option.

Before this change:

• wasTwoFaCodeUsedRecently() treated stale timestamps as “recent”, so old entries could still block login.
• If inserting the used-code record failed with a duplicate key, validation failed immediately, even when the existing record was stale.

After this change:

• The “recently used” check correctly blocks only codes used within BLOCK_TWOFA_CODE_MINUTES.
• On duplicate insert, we now attempt an atomic UPDATE that refreshes the timestamp only if the existing record is stale.
• If that update succeeds, auth continues; if not, auth is rejected (code is still within block window).

Why

A user could be incorrectly blocked from using a valid 2FA code until cleanup ran, due to stale option rows and duplicate-key behavior.

Additional changes

• Added stricter internal typing/docblocks in TwoFactorAuthentication (private/internal methods), aligned with ongoing PHPStan cleanup.

Tests

Added integration coverage in TwoFactorAuthenticationTest for:

• stale record can be reused and timestamp is refreshed
• stale record can be reused without requiring cleanup first

Checklist

• [✔] I have understood, reviewed, and tested all AI outputs before use
• [✔] All AI instructions respect security, IP, and privacy rules

Review

• Functional review done
• Potential edge cases thought about (behaviour of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• New documentation added or existing documentation updated