perf(login): verify Argon2 passwords on a parked worker thread

An Argon2 verify is ~8.9 ms of frozen world per login attempt, successful or
not, so a credential flood is a full-cost stall per packet without needing
valid credentials. Measurement puts the on-loop saving at 3.5-8.9 ms: the
hand-off costs ~220 ns, and the only real residue is the loop's own work
slowing while a memory-hard KDF evicts shared L3.

One worker, not a pool. The per-login contention tax falls with concurrency
while total loop damage rises, so one hasher harms the loop least; and a
single hasher cannot cost the loop more than the inline verify under any
scheduling regime, because at worst it takes an equal share of one core.
That bound is what lets the measurement extrapolate to hardware we cannot
inspect, and a pool breaks it. It also caps live Argon2 arenas at one,
which answers memory exhaustion without a separate mechanism.

Scoped to Argon2-stored accounts. SHA and MD5 protections share a
HashAlgorithm instance whose ComputeHash is not thread safe, and they cost
microseconds anyway. Their one-time rehash into Argon2 stays on the loop
too: it costs a migrating account a single 8.9 ms login exactly as today.

The worker parks on an AutoResetEvent and never spins. The spin in
SerializationThreadWorker exists to wait on a producer mid-drain; there is
no such race here, so this is strictly cheaper at idle. It yields while the
world is in PendingSave or Saving -- PendingSave included, because the
serialization threads are already awake and spinning on an empty queue by
then.

Phrase derivation moves to AccountSecurity.DerivePhrase so verification and
rehash cannot disagree about the rule, which is the shape of the lockout
fixed in #2562. ApplyPasswordUpgrade refuses to write when the stored hash
changed while the verify ran, so a password set mid-flight is not replaced
by a rehash of the one it superseded.

Projects/Server/Events/AccountLoginEvent.cs

@@ -37,6 +37,13 @@ public class AccountLoginEventArgs
     public bool Accepted { get; set; }
 
     public ALRReason RejectReason { get; set; }
+
+    /// <summary>
+    /// No verdict yet: a subscriber moved the password check off the game loop and will reply
+    /// itself once it lands. The packet handler must not send an accept or a reject when this is
+    /// set, or the client receives two answers to one login.
+    /// </summary>
+    public bool Deferred { get; set; }
 }
 
 public static partial class EventSink