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.

tests/api/attached_thumbnail_copy.hurl

@@ -92,6 +92,7 @@ Authorization: Bearer {{token}}
 HTTP 200
 [Captures]
 rendered_thumb: bytes
+rendered_etag: header "ETag"
 
 
 # ─────────────────────────────────────────────────────────────
@@ -112,8 +113,33 @@ Authorization: Bearer {{token}}
 HTTP 200
 [Captures]
 uploaded_thumb: bytes
+uploaded_etag: header "ETag"
 [Asserts]
 bytes != {{rendered_thumb}}
+# The ETag must move with the bytes. It is keyed on the ATTACHED blob's own
+# hash, because uploading a preview leaves the file's content — and so a
+# source-keyed ETag — unchanged. With `immutable` set, an unchanged
+# validator means clients never revalidate and keep the old render for a
+# year.
+header "ETag" != "{{rendered_etag}}"
+
+
+# A client holding the pre-upload validator must be told to refetch.
+GET {{base_url}}/api/files/{{orig_file_id}}/thumbnail/preview
+Authorization: Bearer {{token}}
+If-None-Match: {{rendered_etag}}
+
+HTTP 200
+[Asserts]
+header "ETag" == "{{uploaded_etag}}"
+
+
+# ...and the new one revalidates.
+GET {{base_url}}/api/files/{{orig_file_id}}/thumbnail/preview
+Authorization: Bearer {{token}}
+If-None-Match: {{uploaded_etag}}
+
+HTTP 304
 
 
 # ─────────────────────────────────────────────────────────────
@@ -141,6 +167,12 @@ HTTP 200
 [Asserts]
 bytes == {{uploaded_thumb}}
 bytes != {{rendered_thumb}}
+# Same bytes, so the same validator — the copy's attachment row points at
+# the same blob. This is also what stops the collision a source-keyed ETag
+# would allow: the copy inherits the source hash, so if either side later
+# gets a DIFFERENT preview the two would serve different bytes under one
+# ETag, and a shared cache could hand either to either.
+header "ETag" == "{{uploaded_etag}}"
 
 
 # ─────────────────────────────────────────────────────────────
@@ -184,6 +216,7 @@ HTTP 200
 [Asserts]
 bytes == {{uploaded_thumb}}
 bytes != {{rendered_thumb}}
+header "ETag" == "{{uploaded_etag}}"
 
 
 # ─────────────────────────────────────────────────────────────