test(e2e): re-point the PIN lockout specs at the property that matters

Three specs asserted the OLD policy — that three wrong PINs lock an account —
which is exactly the behaviour the previous commit removed, because that threshold
sat below the per-(IP, name) throttle ceiling and so let any single IP lock any
guest whose display name is readable off the feed.

Rewritten to assert the distinction the fix introduces, which a status code alone
cannot show: both tiers answer 429, but only the account lock costs the VICTIM.
The new specs read the row via db.isPinLocked rather than the response, so:

- one IP hammering /recover is throttled and the account stays UNLOCKED;
- a distributed guesser (counter preloaded via db.setFailedPinAttempts, since no
  single source can reach the threshold any more) still trips the lock, and it
  holds even against the correct PIN;
- concurrent wrong PINs are all counted — the atomicity property the old parallel
  test was really about, now asserted on the counter instead of inferred from a
  429 that the throttle could equally have produced.

The UI spec asserts the user-visible half: after four wrong PINs Dave can still
get into his own account. It also now types the PIN digit by digit rather than
filling and clicking, because the 4th digit auto-submits (pin-auto-submit.spec.ts)
and doing both raced the button's disabled state.

The adversarial spec enables rate_limits_enabled for its own run — it is off by
default in this environment, so without that the throttle tier would silently not
be exercised — and restores it in afterEach so it cannot leak into other specs
sharing the stack.

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

e2e/fixtures/db.ts

@@ -37,6 +37,52 @@ export const db = {
     );
   },
 
+  /**
+   * Is this user's account currently PIN-locked?
+   *
+   * Distinguishes the two ways /recover can answer 429 — the per-(IP, name) throttle, which
+   * costs the attacker, and the account lock, which costs the VICTIM. Only the second one is
+   * weaponizable, so a test asserting "a single IP cannot lock a guest out" has to look at the
+   * row, not at the status code.
+   */
+  async isPinLocked(userId: string): Promise<boolean> {
+    return withClient(async (c) => {
+      const r = await c.query<{ locked: boolean }>(
+        `SELECT (pin_locked_until IS NOT NULL AND pin_locked_until > NOW()) AS locked
+           FROM "user" WHERE id = $1`,
+        [userId]
+      );
+      return r.rows[0]?.locked ?? false;
+    });
+  },
+
+  /**
+   * Preload the wrong-PIN streak, standing in for failures that arrived from other IPs.
+   *
+   * The account lock is deliberately out of reach of any single source, so a test that wants to
+   * exercise it has to simulate the distributed case rather than hammer from one address.
+   * `last_failed_pin_at` is set to now so the 15-minute decay does not immediately reset it.
+   */
+  async setFailedPinAttempts(userId: string, attempts: number) {
+    await withClient((c) =>
+      c.query(
+        `UPDATE "user" SET failed_pin_attempts = $2, last_failed_pin_at = NOW() WHERE id = $1`,
+        [userId, attempts]
+      )
+    );
+  },
+
+  /** Current wrong-PIN streak. Decays after 15 minutes — see User::increment_failed_pin. */
+  async failedPinAttempts(userId: string): Promise<number> {
+    return withClient(async (c) => {
+      const r = await c.query<{ failed_pin_attempts: number }>(
+        `SELECT failed_pin_attempts FROM "user" WHERE id = $1`,
+        [userId]
+      );
+      return r.rows[0]?.failed_pin_attempts ?? 0;
+    });
+  },
+
   async expireSession(userId: string) {
     await withClient((c) =>
       c.query(`UPDATE session SET expires_at = NOW() - interval '1 hour' WHERE user_id = $1`, [