feat(db): idempotency keys, ban-aware counts, and a host audit trail

Four migrations, all additive against a database that already has 001-025 applied.

026 narrows the client-upload idempotency index with `AND deleted_at IS NULL`. The old
index made a soft-deleted row keep its key forever, so a guest who deleted a photo and
re-sent the same one had the retry silently swallowed. The new indexed set is a strict
subset of the old, so it cannot fail on existing rows.

027 adds `client_join_id`, which lets a join retry after a lost response resume the same
account instead of 409ing on a name the caller itself owns. Every existing row gets NULL
and the partial index excludes NULLs, so it indexes nothing at creation.

028 brings the feed view's like/comment counts in line with what the feed actually renders:
a banned guest's rows were still counted, so a card showed "3 comments" above two.
`comment.rs` gets the matching `NOT u.is_banned` on the live read path — the export and
hashtag queries already filtered it, so the two views of one moderation action disagreed.

029 records host moderation actions, which were previously invisible after the fact.

Verified by applying 001-029 to a real Postgres against seeded data, including a
soft-deleted row holding a key and a banned user's like and comment. 026's down-migration
legitimately fails where a deleted and a live row share a key — that is inherent to the
direction, documented in the file, and sqlx never runs downs at boot.

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

backend/migrations/029_host_action_audit.up.sql

@@ -0,0 +1,41 @@
+-- An audit trail for privileged actions (H17).
+--
+-- What existed before: nothing. `grep -i audit` across `handlers/host.rs` and `handlers/admin.rs`
+-- returned no hits. Individual actions logged a `tracing::info!` line, but config changes, gallery
+-- release and event lock/unlock logged nothing at all — and the "audit trail" as a whole was a
+-- 30 MB rotating Docker log that the runbook's own retention settings will discard.
+--
+-- Why it matters here specifically: a host is a promoted GUEST, and `reset_pin` overwrites another
+-- guest's credential and returns the new PIN in the clear. So a host can take over any guest's
+-- account and post as them, and nothing in the record showed it happened (only /recover FAILURES
+-- were logged). At a wedding the people involved know each other; the point is not catching a
+-- villain, it is being able to answer "what happened to my photo?" the next morning without
+-- guessing.
+--
+-- Deliberately append-only in practice: no UPDATE or DELETE path is written for it anywhere. Small
+-- (a few hundred rows for a real event), so no partitioning or retention job.
+
+CREATE TABLE host_action_audit (
+    id           BIGSERIAL PRIMARY KEY,
+    event_id     UUID NOT NULL REFERENCES event(id) ON DELETE CASCADE,
+    -- The privileged caller. NOT a FK with ON DELETE CASCADE: the record must survive the actor's
+    -- account being removed, which is exactly when it is most likely to be wanted.
+    actor_id     UUID,
+    actor_name   TEXT,
+    actor_role   TEXT NOT NULL,
+    -- Short stable slug: 'ban_user', 'unban_user', 'reset_pin', 'delete_upload',
+    -- 'delete_comment', 'release_gallery', 'lock_uploads', 'unlock_uploads', 'patch_config',
+    -- 'promote_user', 'demote_user', 'delete_user'.
+    action       TEXT NOT NULL,
+    -- The guest or object acted upon, when there is one.
+    target_id    UUID,
+    target_name  TEXT,
+    -- Free-form context: the config key and its old/new value, the caption that was removed, etc.
+    -- Never credentials — a reset PIN must not be recoverable from this table.
+    detail       JSONB,
+    created_at   TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+-- The only query shape this needs: "what happened at this event, newest first".
+CREATE INDEX host_action_audit_event_created_idx
+    ON host_action_audit (event_id, created_at DESC);