Account lockout after consecutive failed logins

This is a distinct defense-in-depth control from the rate limiting already implemented: rate limiting counts requests in a rolling window and resets on its own regardless of outcome. Lockout should count consecutive failures and reset immediately to zero the moment a login succeeds -- so a legitimate user who fat-fingers their password twice is never penalized, while a sustained guessing attempt, even one paced slowly enough to stay under the rate limit, still gets cut off.

app/blueprints/auth/lockout.py already has three stub functions (record_failed_login, clear_failed_logins, is_locked_out) wired into login() at the right points -- call sites exist, nothing crashes -- but every function is a no-op / hardcoded False, so no account can ever be locked out.

1. With LOCKOUT_THRESHOLD=4, send 4 consecutive failed logins for one account.
2. Send a 5th login attempt, even with the correct password.
3. Observe: 401, not the expected 423.

The interesting design constraint here is "consecutive," not "total in a window" -- which is exactly what distinguishes this from rate limiting and is why it cannot just reuse check_rate_limit(). Redis is the natural place to keep this counter (mirroring the pattern already used for TOTP replay tracking in totp.py).

Look at how totp.py uses Redis for a small piece of per-user state with a TTL (_last_used_step_key / redis_client.setex) -- the shape is similar here, just keyed by email instead of user_id, and counting failures instead of tracking a step number. record_failed_login(), clear_failed_logins(), and is_locked_out() are already called from the right places in ; implement what is inside them.