fix(auth): reserve the throttle slots before the scrypt verify

In multi-user mode the per-IP and (username, IP) gates read their counts before
the verify and wrote them after it, so a concurrent burst from one IP passed both
on one stale read (29 wrong guesses plus the right password logged in). A request
that passes both gates now takes its slot before the await; a success clears it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/security-architecture.md

@@ -165,6 +165,11 @@ account from another IP still logs in), which is why the per-IP cap is the
 widest. The per-username bucket stays after the verify on purpose: checked
 first, a username-wide lockout let throwaway IPs keep a known account (admin
 included) locked out even with the right password.
+Both pre-verify gates count a request the moment it passes them, before its
+verify starts, so a burst of concurrent attempts cannot all slip through on one
+stale count; a correct password then clears its slot with the rest, and a
+failure is not counted a second time. A verify still in flight therefore holds a
+slot, even one carrying the right password.
 
 ---