Merge branch 'fix/deploy-unattended-blockers' into main

Two independent lines of production hardening diverged at 7d0334b and attacked
overlapping problems. Neither was a superset, so this is a merge of substance
rather than a fast-forward: every conflict was resolved on the merits, and the
losing side's intent was re-checked against the winner rather than assumed.

MIGRATIONS. The branch's 021/022/023 collided with main's already-DEPLOYED
021_hashtag_counts_respect_bans and 022_client_upload_idempotency. Renumbered to
023/024/025 in a prior commit — main's versions are applied in production, so
their version numbers are immutable and the branch's had to move. Verified by
running the full sqlx::test suite, which applies the whole chain from scratch.

RESOLVED IN MAIN'S FAVOUR (the branch would have regressed these):
  * upload-queue.ts wholesale — the branch's copy has ZERO client_upload_id
    references, so taking it would have silently destroyed end-to-end upload
    idempotency, the one thing standing between a lost response and a duplicate
    photo charged twice against the guest's quota.
  * maintenance.rs supervisor — the branch replaced it with a bare tokio::spawn,
    where one panic silently stops session pruning, media reclaim, the temp
    sweep and both HashMap prunes, permanently and with no log line.
  * The decode-budget probe on spawn_blocking, not inline on the async runtime.
  * feed/+page.svelte's 8s debounce + jitter + max-wait + hidden-tab deferral,
    against the branch's naive 800ms — at 100 guests the branch's version walks
    straight into the per-user feed rate limit.
  * db.rs pool tuning, /uploaders, and the docker-compose deployment story.
  * ONE /health, still DB-backed. The branch's split (dependency-free liveness +
    DB-backed readiness) is defensible, but a constant-"ok" /health is the exact
    defect faea555 fixed and verified live, its motive (Caddy's boot gate) is
    already covered by app depends_on db: service_healthy, and the two handlers
    were the same SELECT 1 under two names.

TAKEN FROM THE BRANCH:
  * The large-PNG OOM guard and its bounded-retry counter (023). Together these
    turn a single upload that can OOM-kill a 1G container into a bounded failure
    instead of an infinite restart loop under `restart: unless-stopped`.
  * 024_feed_scalar_counts — the feed no longer aggregates the whole event per
    page. Pure SQL; column names, order and types are unchanged by design.
  * The admin-lockout fix: look the admin up BY ROLE, never by name. 025 also
    frees any guest already squatting on a reserved name.
  * PIN lockout tier ordering, bounded caption/hashtag reads, SSE ticket caps,
    PoolTimedOut -> 503 + Retry-After, and the ffmpeg stderr drain.
  * backfill_video_posters, which main lacked entirely.
  * TempFileGuard, plus sweep_orphan_originals wired into main's SUPERVISED loop
    (not the branch's bare one) — it reclaims final-named originals whose commit
    never happened, a class main's .tmp-only sweep structurally cannot see.
  * shouldAbortForStall, hand-ported into main's upload-queue.ts since that file
    was resolved to main. Widens the watchdog at loadend instead of disarming it,
    bounding a half-open socket at 2 minutes rather than handing the window to
    xhr.timeout (5-60 min) with the whole queue's `processing` latch held.

ALSO: RUST_LOG and EXPORT_PATH pinned in compose. The code fallback was
`debug` (a line per request, all night) and EXPORT_PATH was the one path with a
mount-shaped default that nothing validated.

Verified: cargo check --all-targets, cargo clippy (clean), 144/144 backend tests
against a live Postgres including upload_idempotency and upload_concurrency,
51/51 vitest, svelte-check 0 errors, eslint clean, vite build.

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

backend/migrations/023_derivative_attempts.down.sql

@@ -0,0 +1,3 @@
+DROP INDEX IF EXISTS idx_upload_derivative_backfill;
+ALTER TABLE upload DROP COLUMN IF EXISTS derivative_last_error;
+ALTER TABLE upload DROP COLUMN IF EXISTS derivative_attempts;

backend/migrations/023_derivative_attempts.up.sql

@@ -0,0 +1,23 @@
+-- Bound how many times a permanently-failing upload can be re-processed.
+--
+-- Without this, one poisoned row is an outage. The upload row is committed BEFORE compression
+-- starts, `derivatives_rev` defaults to 0, and `set_derivatives_rev` only runs on success — so
+-- a row whose processing kills the container survives at rev 0, the unconditional startup
+-- backfill re-selects it on the next boot, and `restart: unless-stopped` turns that into an
+-- infinite kill loop. Every restart also drops every SSE stream and truncates every in-flight
+-- upload. That was reachable via a single large PNG (see services/compression.rs), but the
+-- shape is general: any input that can kill or hang the worker repeats forever.
+--
+-- The counter is incremented WRITE-AHEAD, before the work is attempted, because the failure
+-- mode being defended against is a SIGKILL — no error is returned, no handler runs, no Drop
+-- fires. A counter bumped in an error path increments zero times per crash and changes nothing.
+ALTER TABLE upload ADD COLUMN IF NOT EXISTS derivative_attempts SMALLINT NOT NULL DEFAULT 0;
+
+-- Last failure text, so a row that has given up can be diagnosed without reproducing it.
+-- Nothing reads this in code; it exists for the operator.
+ALTER TABLE upload ADD COLUMN IF NOT EXISTS derivative_last_error TEXT;
+
+-- Serves the backfill selection, which now filters on both columns.
+CREATE INDEX IF NOT EXISTS idx_upload_derivative_backfill
+    ON upload (derivatives_rev, derivative_attempts)
+    WHERE deleted_at IS NULL;

backend/migrations/024_feed_scalar_counts.down.sql

@@ -0,0 +1,26 @@
+-- Restore the 016 definition verbatim.
+DROP VIEW IF EXISTS v_feed;
+CREATE VIEW v_feed AS
+SELECT
+    u.id,
+    u.event_id,
+    u.user_id,
+    usr.display_name             AS uploader_name,
+    usr.is_banned,
+    usr.uploads_hidden,
+    u.preview_path,
+    u.thumbnail_path,
+    u.display_path,
+    u.mime_type,
+    u.caption,
+    u.created_at,
+    COUNT(DISTINCT l.user_id)    AS like_count,
+    COUNT(DISTINCT c.id)         AS comment_count
+FROM upload u
+JOIN "user" usr ON u.user_id = usr.id
+LEFT JOIN "like" l  ON l.upload_id = u.id
+LEFT JOIN comment c ON c.upload_id = u.id AND c.deleted_at IS NULL
+WHERE u.deleted_at IS NULL
+  AND usr.uploads_hidden = FALSE
+  AND usr.is_banned = FALSE
+GROUP BY u.id, usr.display_name, usr.is_banned, usr.uploads_hidden;

backend/migrations/024_feed_scalar_counts.up.sql

@@ -0,0 +1,55 @@
+-- Make a feed page cost a page, not the whole event.
+--
+-- The previous definition (016) computed like_count/comment_count with LEFT JOINs and a
+-- GROUP BY. Postgres CAN push the `event_id = $1` qual and the keyset predicate through the
+-- view — verified with EXPLAIN, it uses idx_upload_event_created_id — but it CANNOT push
+-- ORDER BY ... LIMIT across a GroupAggregate. So every feed request aggregated every upload in
+-- the event (times its likes and comments) and only then sorted and took 21 rows. The cost
+-- grew with the event, not with the page, and page 1 — the most expensive one — is exactly
+-- what refreshFeedInPlace refetches on every completed upload, from every open feed in the
+-- venue.
+--
+-- Correlated scalar subqueries move the counts ABOVE the Limit in the plan: they are evaluated
+-- once per returned row, so 21 index lookups instead of a full aggregation.
+--
+-- The rewrite is EXACTLY equivalent, not merely close:
+--   * "like" is keyed (upload_id, user_id), so COUNT(DISTINCT l.user_id) == count(*).
+--   * comment.id is the primary key, so COUNT(DISTINCT c.id) == count(*).
+--   * one row per upload either way — the GROUP BY was on u.id.
+-- Column names, order and types are unchanged (count(*) and COUNT(DISTINCT ...) are both
+-- bigint), so no Rust code changes.
+--
+-- No new index needed: idx_like_upload plus the (upload_id, user_id) PK serve the like
+-- subquery, and idx_comment_upload ... WHERE deleted_at IS NULL matches the comment
+-- subquery's predicate exactly.
+--
+-- One thing a future editor needs to know: the hashtag-filtered feed joins upload_hashtag
+-- against this view. That was safe before only because the GROUP BY collapsed the join
+-- fan-out; it is safe now because the view is one row per upload and upload_hashtag is keyed
+-- (upload_id, hashtag_id) with a single tag filtered. Adding a second tag filter would need
+-- fresh thought.
+
+-- Not CASCADE: if something ever comes to depend on this view, the migration should fail
+-- loudly rather than silently drop it.
+DROP VIEW IF EXISTS v_feed;
+CREATE VIEW v_feed AS
+SELECT
+    u.id,
+    u.event_id,
+    u.user_id,
+    usr.display_name AS uploader_name,
+    usr.is_banned,
+    usr.uploads_hidden,
+    u.preview_path,
+    u.thumbnail_path,
+    u.display_path,
+    u.mime_type,
+    u.caption,
+    u.created_at,
+    (SELECT count(*) FROM "like" l WHERE l.upload_id = u.id)                           AS like_count,
+    (SELECT count(*) FROM comment c WHERE c.upload_id = u.id AND c.deleted_at IS NULL) AS comment_count
+FROM upload u
+JOIN "user" usr ON u.user_id = usr.id
+WHERE u.deleted_at IS NULL
+  AND usr.uploads_hidden = FALSE
+  AND usr.is_banned = FALSE;

backend/migrations/025_reserved_names_and_pin_decay.down.sql

@@ -0,0 +1,11 @@
+-- NOTE: the reserved-name rename in the up migration is NOT reversible. The original names
+-- are not recorded anywhere, and reversing it would in any case re-create the state that
+-- bricked admin login. Rolling back the schema does not roll back that data change.
+DELETE FROM config WHERE key IN (
+    'recover_name_rate_per_15min',
+    'pin_reset_ip_rate_per_min',
+    'upload_edit_rate_per_min',
+    'upload_edit_rate_enabled'
+);
+
+ALTER TABLE "user" DROP COLUMN IF EXISTS last_failed_pin_at;

backend/migrations/025_reserved_names_and_pin_decay.up.sql

@@ -0,0 +1,48 @@
+-- Two independent auth defects that share a migration because they share a table.
+
+-- 1. RESERVED NAMES — free any guest squatting on a name the admin path used to depend on.
+--
+-- Migration 007 made display_name unique per event case-insensitively, and `join` had no
+-- reserved-name guard. So any guest could join as "admin"/"Admin"/"ADMIN" before the operator's
+-- first admin login; admin_login then looked its user up BY NAME, missed (wrong role), fell
+-- through to creating "Admin", violated that unique index, and returned a 500 — permanently,
+-- with no in-app recovery. Moderation, config and gallery release all gone, fixed only by SQL.
+--
+-- The real fix is in code (look the admin up by role, never by name — see auth/handlers.rs).
+-- This clears the state an already-deployed database may be carrying.
+--
+-- RENAMED, NEVER DELETED: the guest keeps their uploads, their PIN and their session. Only
+-- non-admin rows are touched — a real admin row named "Admin" is the expected state.
+UPDATE "user" u
+   SET display_name = u.display_name || ' (' || left(u.id::text, 8) || ')'
+ WHERE u.role <> 'admin'
+   AND lower(u.display_name) IN ('admin', 'administrator', 'host', 'eventsnap');
+
+-- 2. PIN LOCKOUT DECAY.
+--
+-- failed_pin_attempts only ever cleared on a successful recovery or after a lockout expired, so
+-- honest typos accumulated across days: a guest who fat-fingered their PIN twice last night
+-- arrives today already two-thirds of the way to being locked out. With the threshold now
+-- raised (see below) a decay window is what keeps that raise safe rather than merely lenient.
+ALTER TABLE "user" ADD COLUMN IF NOT EXISTS last_failed_pin_at TIMESTAMPTZ;
+
+-- Rate-limit knobs introduced with this release.
+--
+-- recover_name_rate_per_15min (4, was a hardcoded 5): the per-(IP, name) ceiling. It MUST stay
+-- below the account-lock threshold, which is the whole defect — at 5-per-IP against a 3-strike
+-- lock, three requests from one IP locked any guest whose name is visible on the feed, every 15
+-- minutes, forever. The lock threshold moves to 12 in code, so locking a victim now needs at
+-- least three distinct sources while an honest guest never comes close.
+--
+-- pin_reset_ip_rate_per_min (30): /recover/request was the one unauthenticated endpoint with no
+-- per-IP ceiling at all — /join got one in 017 and /recover in 019, and this third one was
+-- simply missed. Its per-name key is attacker-chosen, so cycling names minted a fresh bucket
+-- every time and the per-IP cost was unbounded.
+--
+-- upload_edit_rate_per_min (30): PATCH /upload/{id} had no rate limit of any kind.
+INSERT INTO config (key, value) VALUES
+    ('recover_name_rate_per_15min', '4'),
+    ('pin_reset_ip_rate_per_min',   '30'),
+    ('upload_edit_rate_per_min',    '30'),
+    ('upload_edit_rate_enabled',    'true')
+ON CONFLICT (key) DO NOTHING;