fix(upload): stop a late retry from undoing a host takedown

Migration 026 freed the idempotency key as soon as deleted_at was set, so a
retry after a delete uploads afresh instead of 409ing forever. That rationale
only considered the GUEST deleting. deleted_at is also set by
host_delete_upload, and there the same rule reverses a moderation decision:

  1. Guest uploads; the row commits and the photo appears, but the response
     is lost on the way back — the flaky-wifi case the key exists for — so
     the phone keeps the queue item.
  2. The host takes the photo down. Epoch bumped, keepsake rebuilt without it.
  3. The phone reconnects ten minutes later and retries. The key is free, the
     INSERT succeeds, and the photo is back — in the feed and in the next
     keepsake, under a NEW uuid that matches nothing in the host's moderation
     history, with nothing logged to say a takedown was reversed.

Migration 031 keeps the key claimed for a host takedown and releases it only
for a guest's own delete, so the retry resolves to the duplicate path and is
refused. The refusal now says why ("von den Gastgebern entfernt") rather than
"already processed", which invites another try.

The index predicate and the ON CONFLICT arbiter are changed in lockstep;
these queries are not compile-checked, so a drift between them is a 500 on
exactly the retries the index exists to serve. Verified against a real
Postgres: live retry suppressed, host takedown holds the key, guest delete
releases it. The integration test's copy of the insert is updated too — it is
verbatim by design, and a stale copy would have kept passing.

backend/tests/upload_idempotency.rs

@@ -26,7 +26,7 @@ async fn create_upload(
     let row: Option<(Uuid,)> = sqlx::query_as(
         "INSERT INTO upload (event_id, user_id, original_path, mime_type, original_size_bytes, caption, client_upload_id)
          VALUES ($1, $2, $3, $4, $5, $6, $7)
-         ON CONFLICT (client_upload_id) WHERE client_upload_id IS NOT NULL AND deleted_at IS NULL DO NOTHING
+         ON CONFLICT (client_upload_id) WHERE client_upload_id IS NOT NULL AND (deleted_at IS NULL OR taken_down_by_host) DO NOTHING
          RETURNING id",
     )
     .bind(event_id)
@@ -161,7 +161,10 @@ async fn a_deleted_upload_is_not_replayed(pool: PgPool) {
     let id = create_upload(&pool, event_id, user_id, "originals/a.jpg", Some(key))
         .await
         .expect("first insert");
-    sqlx::query("UPDATE upload SET deleted_at = NOW() WHERE id = $1")
+    // `taken_down_by_host = FALSE` — the GUEST deleted their own photo. See migration 031 and the
+    // sibling test below: the two cases must behave differently, and this is the one that frees
+    // the key.
+    sqlx::query("UPDATE upload SET deleted_at = NOW(), taken_down_by_host = FALSE WHERE id = $1")
         .bind(id)
         .execute(&pool)
         .await
@@ -198,3 +201,68 @@ async fn a_deleted_upload_is_not_replayed(pool: PgPool) {
         "the live row is the one the replay lookup must now find"
     );
 }
+
+/// The mirror of the test above, and the case migration 026's rationale did not consider.
+///
+/// `deleted_at` is set by the guest deleting their own photo AND by `host_delete_upload`. Freeing
+/// the idempotency key on both meant a takedown could be silently undone: the guest's response was
+/// lost, so their queue still holds the item; the host removes the photo (bumping the keepsake
+/// epoch and rebuilding the archive without it); the phone reconnects ten minutes later and
+/// retries; the key is free, the INSERT succeeds, and the photo is back in the feed and in the next
+/// keepsake — under a NEW uuid that matches nothing in the host's moderation history, with nothing
+/// logged to say a takedown was reversed. The host has to find and delete it a second time.
+///
+/// Migration 031 keeps the key claimed for a host takedown, so the retry resolves to the duplicate
+/// path and is refused. Refusing is the correct answer here: the photo was deliberately removed.
+#[sqlx::test]
+async fn a_host_takedown_is_not_undone_by_a_late_retry(pool: PgPool) {
+    let event_id = seed_event(&pool, "wedding").await;
+    let user_id = seed_user(&pool, event_id, "Übermütiger Uwe").await;
+    let key = Uuid::new_v4();
+
+    let id = create_upload(&pool, event_id, user_id, "originals/a.jpg", Some(key))
+        .await
+        .expect("first insert");
+
+    // SRC: `models/upload.rs::Upload::soft_delete_in_event` with `by_host = true`.
+    sqlx::query("UPDATE upload SET deleted_at = NOW(), taken_down_by_host = TRUE WHERE id = $1")
+        .bind(id)
+        .execute(&pool)
+        .await
+        .expect("host takedown");
+
+    let retried = create_upload(&pool, event_id, user_id, "originals/a.jpg", Some(key)).await;
+    assert_eq!(
+        retried, None,
+        "a retry after a HOST takedown must be suppressed — otherwise the phone silently \
+         reinstates a photo the hosts removed"
+    );
+
+    let live: i64 = sqlx::query_scalar(
+        "SELECT count(*) FROM upload WHERE client_upload_id = $1 AND deleted_at IS NULL",
+    )
+    .bind(key)
+    .fetch_one(&pool)
+    .await
+    .expect("count");
+    assert_eq!(live, 0, "the taken-down photo must stay gone");
+
+    // And the handler must be able to tell the guest WHY, rather than "already processed".
+    // SRC: `models/upload.rs::Upload::taken_down_by_client_upload_id`.
+    let was_taken_down: bool = sqlx::query_scalar(
+        "SELECT EXISTS (
+             SELECT 1 FROM upload
+             WHERE client_upload_id = $1 AND user_id = $2
+               AND deleted_at IS NOT NULL AND taken_down_by_host
+         )",
+    )
+    .bind(key)
+    .bind(user_id)
+    .fetch_one(&pool)
+    .await
+    .expect("takedown lookup");
+    assert!(
+        was_taken_down,
+        "the refusal must be attributable to a takedown so the queue can say so"
+    );
+}