fix(upload): refuse undecodable images at the door, and stop retrying them

Two halves of the same complaint: an oversized photo was accepted with a 201 and
then silently soft-deleted minutes later, after the worker had burned six seconds
of backoff re-reaching a conclusion it could not change.

Admission. The compression budget now runs at upload time, against the header
only, so a guest is told immediately and told why:

  "Bild hat zu viele Bildpunkte (ca. 99 Megapixel) und kann nicht verarbeitet
   werden. Bitte verkleinere es und lade es erneut hoch."

instead of watching the photo vanish behind a vague "could not be processed" —
which arrived only if they happened to still be on the feed with that card
loaded. Nothing is stored, so there is no row to soft-delete and no orphan for
the sweep to reclaim.

Admission and the worker share ONE function (`decoder_within_budget`), so they
cannot drift apart and start disagreeing about what is acceptable — a photo
accepted at the door and rejected by the worker would be worse than either
behaviour alone. The worker keeps its own check: the backfill decodes files that
predate this check, and defence in depth is the whole reason the budget exists.

Retries. The loop retried every failure, including ones that are a property of
the input. An image over the budget, a corrupt file, an unsupported format: each
fails identically on all three attempts, so the only effect was 2s + 4s of sleep
and three near-identical warnings before the same outcome. `is_permanent_image_error`
classifies the `ImageError` variants that cannot change between attempts — Limits,
Unsupported, Decoding — and the loop gives up on those at once. `IoError` is
deliberately excluded: an ENOSPC while writing a derivative is exactly the
transient case the retry exists for, and misclassifying it would turn a blip back
into the data loss round 1 fixed. Measured: retry log lines went from 3 per
oversized upload to 0.

Tests: unit tests for both sides of the classifier (a Limits error is permanent, a
missing file is not) and for admission agreeing with the decoder on accept AND
reject. The e2e spec is rewritten for the new contract — 400 with an actionable
message, nothing stored, backend alive after a burst of four — plus a mirror
asserting an ordinary photo still uploads and processes, since a budget that
rejected everything would satisfy the other two.

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

backend/src/services/compression.rs

@@ -74,6 +74,11 @@ impl CompressionWorker {
             // an ENOSPC spike while several guests upload at once, a momentary DB-pool
             // exhaustion, a panic inside the image codec — and the give-up path is
             // user-visible data loss, so it is worth a few seconds to avoid entering it.
+            //
+            // But only for failures that CAN clear. An image that exceeds the decode budget,
+            // is corrupt, or is in an unsupported format fails identically on every attempt,
+            // so retrying it just burns 2s + 4s of backoff and writes three near-identical
+            // warnings before reaching the same conclusion. Give up on those immediately.
             let mut attempt = 1u32;
             let outcome = loop {
                 match worker
@@ -81,7 +86,10 @@ impl CompressionWorker {
                     .await
                 {
                     Ok(v) => break Ok(v),
-                    Err(e) if attempt < Self::MAX_PROCESS_ATTEMPTS => {
+                    Err(e)
+                        if attempt < Self::MAX_PROCESS_ATTEMPTS
+                            && !crate::services::imaging::is_permanent_image_error(&e) =>
+                    {
                         tracing::warn!(
                             error = ?e, %upload_id, attempt,
                             "compression attempt failed; retrying"