fix(thumbnails): ETag names the blob actually served

fe9c4f49 keyed the ETag on the SOURCE file's content hash. That is wrong
whenever the response comes from a satellite table, and for attachments
it is wrong in two ways.

Uploading a preview does not change the file's content, so a
source-keyed ETag does not change either — and with `immutable` set,
clients never revalidate and keep the previous render for up to a year.
The exact staleness fe9c4f49 set out to fix, re-entering through the
attachment path.

Worse: a copy inherits the source hash, so an original and a copy have
identical ETags. Give either one a different uploaded preview and they
serve different bytes under one validator, which a shared cache may hand
to either request. That is a collision, not just staleness.

thumbnail_content_id resolves the identity through the same tier
precedence the read path uses: an attached blob's own hash, else a
derived blob's own hash, else the source-keyed form. An ETag naming a
different tier than the one answering is worse than a coarse one, so the
two orders must not drift.

Derived-hash keying is strictly better than source-keying and never
worse. The sidecar and the derived row are written from the same bytes;
where they can diverge — a sidecar re-rendered while the derived row
stays pinned by ON CONFLICT DO NOTHING — source-keying is wrong too,
because the renderer is not part of that key. This is the step 10 change
arriving early, forced by the attachment case; the plan note stands for
the read-order flip itself.

Known gap: a legacy ext-{file_id}.jpg with no file_attached_blobs row
yet falls through to the source-keyed form. No worse than today, and it
resolves when the import backfills.

attached_thumbnail_copy.hurl now asserts ETags, which is why this went
unnoticed: it compared bytes only, and thumbnail_etag_content_keyed
covers content replacement rather than preview upload. A fresh GET
returned the right bytes throughout — the same "healthy locally, broken
for anyone caching" shape as the two bugs before it.

src/interfaces/api/handlers/file_handler.rs

@@ -487,18 +487,22 @@ impl FileHandler {
             Ok(h) => h,
             Err(err) => return AppError::from(err).into_response(),
         };
-        let etag = {
-            let (s, f) = (thumb_size.as_str(), format.as_str());
-            let mut e = String::with_capacity(9 + blob_hash.len() + s.len() + f.len());
-            e.push_str("\"thumb-");
-            e.push_str(&blob_hash);
-            e.push('-');
-            e.push_str(s);
-            e.push('-');
-            e.push_str(f);
-            e.push('"');
-            e
-        };
+        // The identity of the bytes about to be served, resolved through the
+        // same tier precedence the read path uses — an uploaded preview's own
+        // hash, else a derived thumbnail's own hash, else the source-keyed
+        // form. See `ThumbnailService::thumbnail_content_id`.
+        let etag = format!(
+            "\"{}\"",
+            thumbnail_service
+                .thumbnail_content_id(
+                    &id,
+                    &blob_hash,
+                    thumb_size.into(),
+                    format,
+                    Some(&state.core.dedup_service),
+                )
+                .await
+        );
         if let Some(if_none_match) = headers.get(header::IF_NONE_MATCH)
             && let Ok(val) = if_none_match.to_str()
             && (val == etag || val == "*")