Failed-attempt warning addresses two mutually exclusive audiences simultaneously

Problem

The notice shown after any failed 2FA attempt (class-two-factor-core.php lines 1027–1028):

WARNING: Your account has attempted to login %d times without providing a valid two factor token. The last failed login occurred %s ago. If this wasn't you, you should reset your password.

The message speaks to two mutually exclusive people at the same time:

• The legitimate account holder — addressed by "your account" and "you should reset your password"
• A hypothetical attacker reading the form — implied by "if this wasn't you"

In practice, the person reading this message is almost always the legitimate user, who just mistyped their verification code. Telling them "if this wasn't you, reset your password" in response to their own failed attempt is alarming and misleading. It implies they may have been compromised when the most likely explanation is a typo.

If the goal is to alert the user to unauthorized access attempts, the message should be specific about what that means and when it applies — not appended as a hedge to every failed attempt.

Impact

• Legitimate users who mistype their code are told to reset their password unnecessarily
• The dual-audience framing makes the message unclear to both audiences
• Affects all providers, not just email

Suggested direction

Separate the two concerns:

1. Show the failure count and timestamp as informational context (no alarming language for the common case of a typo)
2. Reserve the "reset your password" prompt for cases where the failure count or pattern actually suggests unauthorized access — or remove it from this message entirely and rely on the existing compromised-password reset flow

Related

• Two_Factor_Core::maybe_show_last_login_failure_notice()
• Two_Factor_Core::should_reset_password() — the existing flow that handles the compromised-password case separately

Start with class-two-factor-core.php at Two_Factor_Core::maybe_show_last_login_failure_notice() and compare it with Two_Factor_Core::should_reset_password(). Decide how the notice and existing compromised-password flow should be separated, then verify that failed-attempt context is shown without misleading legitimate users and that the reset flow remains responsible for compromised-password cases.