feat(thumbnails): WebP output with Accept content negotiation

Thumbnails are now generated eagerly as lossy WebP (the primary codec) and
served to clients that advertise `Accept: image/webp`; JPEG is kept as a lazy
fallback for older clients and NextCloud, generated on first request and then
cached like WebP.

- ThumbnailFormat{Webp,Jpeg} enum threaded through encode/render/generate, the
  on-disk path ({hash}.webp / {hash}.jpg), the moka cache key
  (file_id, size, format), and cleanup (both formats removed).
- file_handler: parse Accept -> format, format-keyed ETag, `Vary: Accept` on
  every response (incl. 304) so shared caches never serve the wrong codec;
  Content-Type is byte-sniffed (infer) so it always matches the bytes.
- preview_handler (NextCloud) pins JPEG.
- webp = "0.3" (vendored libwebp via cc, no system dependency).

WEBP_QUALITY=82, chosen via a quality sweep (bench Table E1): SSIM within
~0.005 of JPEG q80 (imperceptible at thumbnail scale) for ~62% fewer bytes. On
the photo-realistic bench corpus the full set (3 sizes x 3 photos) drops 65.6%
(213->73 KB); real photos with edges/text land nearer ~25-40%. Encode is +5ms,
paid once in the eager background generator (off the request path).

The bench corpus is now photo-realistic (per-channel sums of low-frequency
sinusoids) instead of white noise, which had distorted codec byte ratios.
Methodology + numbers in benches/WEBP.md.

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

Cargo.toml

@@ -46,6 +46,10 @@ jpeg-decoder = "0.3"
 # SIMD (AVX2/SSE4.1/NEON) image resizing for thumbnails — far faster than the
 # `image` crate's scalar resampler, and it speeds every format (incl. PNG/WebP).
 fast_image_resize = "5"
+# Lossy WebP encoding for thumbnails. The `image` crate's webp feature is
+# lossless-only; this binds libwebp (vendored + built via `cc`, no system dep)
+# for quality-controlled lossy output (~25-30% smaller than JPEG at equal SSIM).
+webp = "0.3"
 id3 = "1.17"
 mp3-duration = "0.1"
 kamadak-exif = "0.6.1"