Wire up userLock brute-force protection (stored procedure exists but is unused)

Summary

The userLock stored procedure exists in coreSchema.sql (line 181) and implements brute-force protection: increments badLoginCount on failed logins, suspends the account for 30 minutes after 3 failures within 10 minutes. However, it has never been called from Java code — it was added as part of the schema in #344 (2018) with no follow-up.

The read side partially works: authUser() already checks suspendedUntil and rejects suspended users, and calls userBadLoginReset on successful login. The missing piece is calling userLock on failed password verification.

Considerations before implementing

• Account lockout DoS: anyone who knows a username can lock the account by submitting 3 bad passwords. In a classroom setting, students could lock each other (or the admin) out mid-session.
• Needs an admin toggle: there's no setting to enable/disable this. Should add a key to the settings table (e.g. enableBruteForceProtection) so admins can opt in.
• SSO users: userLock takes userName, so failed password attempts against SSO accounts could incorrectly lock them out of SSO. The failure path should skip lockout for non-login type users.
• User enumeration timing: calling userLock only for existing users creates a timing side-channel. Consider whether this matters for a training platform.

References

• Stored procedure: src/main/resources/database/coreSchema.sql line 181
• Auth method: src/main/java/dbProcs/Getter.java authUser()
• Surfaced during review of #821