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/027_join_idempotency.up.sql

@@ -0,0 +1,34 @@
+-- Idempotency key for /join, supplied by the client.
+--
+-- The failure this closes (H16) is the single most likely failure of the evening, on step one
+-- of the product. `/join` commits the user row AND the bcrypt hash of the PIN, but the PLAINTEXT
+-- PIN exists nowhere except the HTTP response body. So:
+--
+--   1. guest scans the QR in the venue car park, taps "Beitreten"
+--   2. the server creates the account and hashes the PIN
+--   3. the response is lost on the way back — the 5G-to-nothing transition every wedding venue
+--      has, or the AP handing off
+--   4. the client retries; the name is now taken, so it 409s
+--   5. the client shows a PIN entry form for a PIN THAT WAS NEVER DISPLAYED
+--
+-- The guest is locked out of their own brand-new account, and the only recovery is finding a
+-- host with a dashboard open. `/upload` already solved exactly this with `client_upload_id`;
+-- join never got the same treatment.
+--
+-- With a key, a retry is recognised as the same join and answered with a usable PIN. We do NOT
+-- store the plaintext to replay it — see the handler: a retry ROTATES the PIN. That is sound
+-- precisely because the original was never shown to anybody, so there is nothing to preserve,
+-- and it keeps this table free of recoverable credentials.
+
+ALTER TABLE "user" ADD COLUMN client_join_id UUID;
+
+-- Partial, for the same reasons as `upload_client_upload_id_key`: index only the rows that
+-- carry a key, and state the rule exactly. NULL is allowed and unconstrained, so any client
+-- that does not send one (and every row that predates this column) behaves exactly as before.
+--
+-- Scoped per event as well as per key. The key is a client-generated v4 UUID so a cross-event
+-- collision is not realistic, but a reused install genuinely has two events in one table and
+-- "this join belongs to that event" is the property we actually mean.
+CREATE UNIQUE INDEX user_client_join_id_key
+    ON "user" (event_id, client_join_id)
+    WHERE client_join_id IS NOT NULL;