media: H.264 fallback beside every AV1, and the post links the H.264

The AV1-only publish lasted four hours in the wild: the first viewer on
mobile Safari got "bad media error" from the raw file, because a post's
link is fetched raw — Lemmy apps and browsers play that exact URL, with
no <source> negotiation in front of it. The previous commit's note
("--raw ... if that audience matters") had it backwards: the audience
that cannot play AV1 is not a per-post judgement call, it is whoever
happens to open the thread on an iPhone.

So publish-media.sh now emits two encodings and points the post at the
compatible one:

  * Every video transcode also produces <hash>.h264.mp4 (x264 crf 23,
    same denoise, same frames), uploaded beside the AV1 under the AV1's
    hash — the poster's sibling-naming trick, reused, so fetch-media.sh
    finds it by name with nothing to look up.
  * The printed URL to paste into the post is the H.264 one. pict-rs
    can thumbnail it too, so instance thumbnails come back as a bonus.

fetch-media.sh adopting an own-origin .h264.mp4 URL swaps the AV1 back
in as the page's primary when it is on the mount, and records the H.264
as `fallback` in posts.json. The renderer turns a non-empty fallback
into a <source> pair: the AV1 first with an explicit codecs parameter —
both files are video/mp4, so the parameter is the only thing that lets
a non-AV1 browser skip to the file it can play — and the H.264 second.
Browsers with AV1 keep downloading the small file; Safari before 17
gets one that plays instead of an element that will not.

e2e gains the matching conditional gate: a page offering an av01
<source> must offer an .h264.mp4 one, so an AV1 video can never again
ship without its fallback.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

deploy/README.md

@@ -132,8 +132,13 @@ pointing at its original URL rather than losing the post.
 
 **The recommended flow is to put a recording on catcrafts.net before writing the
 post, and use that URL as the post's link.** Run `tools/publish-media.sh
-recording.mp4`; it transcodes, uploads to the media mount under its content hash,
-and prints a `https://catcrafts.net/media/<hash>.mp4` URL to paste into the post.
+recording.mp4`; it transcodes to AV1 *and* an H.264 sibling, uploads both to the
+media mount under the AV1's content hash, and prints a
+`https://catcrafts.net/media/<hash>.h264.mp4` URL to paste into the post. The
+H.264 one on purpose: a post's link is fetched raw — Lemmy apps and browsers play
+that exact file, with no negotiation in front of it — so it must be the encoding
+everything can play. (An AV1 link posted before this existed drew "bad media
+error" reports from iPhones within hours.)
 
 `fetch-media.sh` recognises its own origin and **adopts** such a URL: it rewrites
 it to `/media/<hash>` and probes the local file for dimensions, downloading
@@ -143,6 +148,12 @@ file host once hit `MAX_BYTES` (64 MB), so the entry kept its original URL, and
 the deploy then failed the e2e "media origin" check on a file that was sitting on
 our own disk the entire time.
 
+Adopting a `<hash>.h264.mp4` URL swaps the AV1 sibling back in as the page's
+primary `<source>` when it is on the mount, keeping the H.264 as the fallback
+`<source>`. So the post links the compatible file, while browsers that can take
+AV1 download the small one — the `codecs` parameter on the first source is what
+lets the rest skip it.
+
 The transcode matters as much as the hosting. Phone recordings are wildly
 oversized for what they show — that same 167 MB clip was 78 s of a dark room at
 17 Mbps, and denoising into AV1 gives the same picture in 15 MB. It also **bakes
@@ -154,15 +165,18 @@ correct too — but transcoding means nothing downstream has to know.)
 
 Two things to know about publishing AV1:
 
-* Nothing emits a fallback encoding and `<video>` carries a single `src`, so
-  browsers without AV1 (Safari before 17, Apple hardware older than A17/M3) get
-  an element that will not play. Use `publish-media.sh --raw`, or a H.264
-  re-encode, when that matters for a particular post.
+* Browsers without AV1 (Safari before 17, Apple hardware older than A17/M3) get
+  the `<hash>.h264.mp4` sibling: on the site via the second `<source>`, on the
+  fediverse because that sibling *is* the posted URL. `--raw` skips the
+  transcode and the fallback both, so a raw AV1 upload recreates the
+  will-not-play problem — use it for files that are already universally
+  playable.
 * Lemmy's `pict-rs` will not generate a thumbnail from an AV1 file, so a
   self-hosted video usually arrives with no `poster`. `publish-media.sh` uploads
   a poster frame beside the video, named `<video-hash>.poster.webp`, and
   `fetch-media.sh` falls back to that sibling when the instance supplied nothing.
-  A thumbnail the instance *did* provide always wins.
+  A thumbnail the instance *did* provide always wins. (Posting the H.264 URL
+  also means pict-rs can thumbnail it again, so instance thumbnails come back.)
 
 An own-origin URL naming a file that is **not** on the mount is deliberately left
 pointing at its original URL rather than rewritten. That is a post published