test(e2e): de-vacuum security tests; add quota, authz-sweep, keepsake-regen coverage

An audit found tests that pass on broken code. The dominant pattern: fire a security
assertion at the all-zeros UUID and accept [403, 404] — the 404 comes from the resource
LOOKUP, not the guard, so the guard can be deleted and the test still passes. Repaired to
use real resources and demand exactly 403:
  - banned-user cannot like / comment (the only coverage of those ban invariants)
  - host cannot promote a real guest (or self) to admin — asserts nobody's role changed
  - IDOR comment-delete already used a real resource; kept
Also inverted recovery.spec's "unknown name → nicht gefunden" test: that asserted the exact
account-enumeration oracle the F4 fix removed, so restoring the vuln would have made it
pass. Now: an unknown name must be byte-identical to a wrong PIN.

New coverage for paths that ran in production but in zero tests:
  - quota.spec.ts: storage quota enforcement (413 over-limit, atomic increment under two
    uploads held mid-body so both carry a stale total=0 — the real race; a naive Promise.all
    version was itself vacuous and is documented as such). Proven to fail without the guard.
  - authz-sweep.spec.ts: table-driven guest→403 / host→403 over ALL 19 privileged routes +
    anonymous + __truncate. No live hole found; the whole surface is now locked.
  - ban / unban / host-comment-delete AFTER release regenerate the keepsake (data-loss
    paths that were dead under test); comment-delete mid-build doesn't strand the ZIP.

Lower-severity de-vacuuming: 10 MB comment test hit Caddy's 502 before the real 500-char
cap (now seeds a real upload, 501→400 / 500→201, mutation-verified); XSS name payloads
shortened under the 50-char cap so they actually store+render; ui-rendering XSS test now
proves the payload rendered before asserting no <b>; export page-object locators fixed to
the real "Download" label with a positive empty-state anchor; avatar palette spread test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

e2e/specs/07-adversarial/auth-tampering.spec.ts

@@ -110,7 +110,7 @@ test.describe('Adversarial — PIN brute-force', () => {
     expect(correct.status).toBe(429);
   });
 
-  test('parallel wrong-PIN attempts may NOT all hit lockout (race-condition finding)', async ({ guest }) => {
+  test('parallel wrong-PIN attempts still lock the account (counter is not lost to the race)', async ({ guest }) => {
     const g = await guest('BruteParallel');
     const wrong = g.pin === '0000' ? '1111' : '0000';
 
@@ -124,12 +124,22 @@ test.describe('Adversarial — PIN brute-force', () => {
       )
     );
     const statuses = attempts.map((r) => r.status);
-    expect(statuses.filter((s) => s === 200)).toHaveLength(0);
-    // Documented behavior: lockout counter may race so not every status is 429.
-    // Critical invariant: no attempt succeeded.
-    if (!statuses.some((s) => s === 429)) {
-      console.warn('[finding] PIN-attempt counter races under parallel requests — none hit lockout.');
-    }
+    expect(statuses.filter((s) => s === 200), 'a wrong PIN must never authenticate').toHaveLength(0);
+
+    // The in-flight requests all read `pin_locked_until` before any of them wrote it, so
+    // *which* of the 10 come back 429 is genuinely racy and can't be asserted. What is NOT
+    // racy — and is the property this test exists to guard — is the state left behind:
+    // `failed_pin_attempts` is incremented with an atomic `SET x = x + 1 ... RETURNING`, so
+    // 10 wrong PINs must push it past the 3-strike threshold and leave the account locked.
+    //
+    // We prove that with a follow-up request using the CORRECT pin: it must be refused with
+    // 429 (locked), not 200. Delete the lockout counter and this line goes 200 → red.
+    const correct = await fetch(`${BASE}/api/v1/recover`, {
+      method: 'POST',
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify({ display_name: g.displayName, pin: g.pin }),
+    });
+    expect(correct.status, 'after 10 wrong PINs the account must be locked, even for the right PIN').toBe(429);
   });
 });