test(e2e): make nine red specs assert the contracts the code actually implements

The e2e suite had never been run during this audit. It failed 9 of 256; seven of those
predated the audit's changes, established by building a stack from a clean HEAD worktree
and running the same specs against it rather than guessing.

Most were stale assertions rather than product defects:

- quota.spec solved for a target limit using the observed uploader count, but the divisor is
  max(active, estimated_guest_count, 1) and that config seeds at 100 — so every limit it
  aimed for came out 100x small and every "within quota" upload 413'd.
- rate-limit-shared-nat destructured `ticket` from a 429 body and fetched with
  `ticket=undefined`, turning the 429 under test into an unrelated 401. It also faked a
  release with no archive on disk, so the mint's pre-check 404'd and the per-day limiter was
  never reached; it now does a real release and asserts 200 rather than "not 429".
- ddos allowed only [200,429] from ten concurrent streams, so it failed on the very defence
  it exercises: four tickets per session survive and the rest correctly 401. Now asserts
  exactly four, which a tightened cap or an inverted eviction order would catch.
- auth-tampering asserted a throttled IP is refused EVEN with the correct password. That
  contract was deliberately removed — it let any phone on the venue NAT lock the operator
  out of their own admin panel, with a circular escape hatch. Inverted, plus a new check
  that a success does not refill an attacker's bucket.
- moderation-ui assumed a ban leaves a comment "stuck on screen"; `list_for_upload` filters
  banned authors, so it is hidden from everyone including the host. Now pins the pair that
  matters — the ban hides it, and the host's permanent removal survives an unban — and the
  UI leg it used to own is restored as a separate test on a reachable comment.

The export specs mint with `?kind=` now that a download ticket is bound to one archive, and
four of them assert the mint's 404 rather than the download's: with the kind always known,
the pre-check refuses up front instead of after charging a daily download for an archive
that cannot be served.

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

e2e/specs/10-flow-review/export-reopen-rerelease.spec.ts

@@ -80,8 +80,16 @@ async function exportStatus(jwt: string): Promise<any> {
   return res.json();
 }
 
-async function mintTicket(jwt: string): Promise<string> {
-  const res = await post('/api/v1/export/ticket', jwt);
+/** The raw mint response. `/export/ticket` pre-validates that the archive is servable, so an
+ *  unavailable keepsake is refused HERE — before one of the guest's three daily downloads is
+ *  charged for an archive that cannot be served. */
+function mintTicketResponse(jwt: string, kind: 'zip' | 'html' = 'zip') {
+  return post(`/api/v1/export/ticket?kind=${kind}`, jwt);
+}
+
+async function mintTicket(jwt: string, kind: 'zip' | 'html' = 'zip'): Promise<string> {
+  // `kind` is REQUIRED: the ticket is bound to one archive (see TicketKind::Download).
+  const res = await post(`/api/v1/export/ticket?kind=${kind}`, jwt);
   return (await res.json()).ticket;
 }
 
@@ -294,9 +302,11 @@ test.describe('Flow re-review — reopen→re-release export integrity + stale-k
     );
     expect(ev.released_at, 'reopen clears the release timestamp').toBeNull();
 
-    const ticket = await mintTicket(host.jwt);
-    const dl = await fetch(BASE + '/api/v1/export/zip?ticket=' + encodeURIComponent(ticket));
-    expect(dl.status, 'a reopened event serves no keepsake').toBe(404);
+    // Refused at the MINT, not one step later at the download: the ticket is bound to an archive,
+    // so the pre-check always knows which one to resolve and answers honestly up front.
+    expect((await mintTicketResponse(host.jwt)).status, 'a reopened event serves no keepsake').toBe(
+      404
+    );
   });
 
   test('open ‖ release churn always converges to a consistent, downloadable keepsake', async ({
@@ -387,11 +397,12 @@ test.describe('Flow re-review — reopen→re-release export integrity + stale-k
 
     expect(
       res.status,
-      'an upload whose body completed after the release MUST be rejected (403 uploads_locked). ' +
-        'A 201 here means the server accepted a photo it will never put in the keepsake — silent, ' +
-        'permanent data loss.'
+      'an upload whose body completed after the release MUST be rejected (403). A 201 here means ' +
+        'the server accepted a photo it will never put in the keepsake — silent, permanent data loss.'
     ).toBe(403);
-    expect((await res.json()).error).toBe('uploads_locked');
+    // `gallery_released`, matching the pre-flight check: the release is what rejected this, and
+    // that code is the one that PARKS the blob instead of re-pushing it on the retry ladder.
+    expect((await res.json()).error).toBe('gallery_released');
 
     // And the keepsake holds exactly the one upload that was genuinely committed before the release.
     await waitExportDone(host.jwt);
@@ -679,10 +690,7 @@ test.describe('Flow re-review — reopen→re-release export integrity + stale-k
     expect(failed.zip.status).toBe('failed');
 
     // Stuck: the keepsake is not downloadable and no amount of re-releasing helps.
-    const ticket = await mintTicket(host.jwt);
-    expect(
-      (await fetch(BASE + '/api/v1/export/zip?ticket=' + encodeURIComponent(ticket))).status
-    ).toBe(404);
+    expect((await mintTicketResponse(host.jwt)).status).toBe(404);
     // ("Galerie wurde bereits freigegeben." — this is the dead end the rebuild endpoint exists for.)
     expect((await post('/api/v1/host/gallery/release', host.jwt)).status).toBe(400);
 

e2e/specs/10-flow-review/upload-lock-code.spec.ts

@@ -36,7 +36,15 @@ test.describe('Upload — locked event uses a distinct, reversible 403 (audit fi
     expect(ok.status, 'upload succeeds once the host reopens').toBeLessThan(300);
   });
 
-  test('released gallery → 403 uploads_locked (also reversible via reopen)', async ({ host }) => {
+  test('released gallery → 403 gallery_released, the PARKING code (not uploads_locked)', async ({
+    host,
+  }) => {
+    // `release ⇒ lock`, so a released gallery satisfies both conditions and the handler's check
+    // ORDER decides which code the guest gets. It must be the release one, and the difference is
+    // not cosmetic: `uploads_locked` charges a retry attempt and re-pushes the whole photo on the
+    // backoff ladder, against an answer that cannot change until a host acts. `gallery_released`
+    // parks it — blob kept, nothing re-sent, and the guest is told to ask the hosts to reopen.
+    // This asserted `uploads_locked` while the release branch was unreachable dead code.
     const rel = await fetch(`${BASE}/api/v1/host/gallery/release`, {
       method: 'POST',
       headers: { Authorization: `Bearer ${host.jwt}` },
@@ -49,6 +57,6 @@ test.describe('Upload — locked event uses a distinct, reversible 403 (audit fi
     });
     expect(rejected.status).toBe(403);
     const body = await rejected.json();
-    expect(body.error).toBe('uploads_locked');
+    expect(body.error).toBe('gallery_released');
   });
 });