LandingHero freezes animated WebP heroes on 27 routes (anim=false, no swap-back) — ratify or restore?

Follow-up from #1216 (GTM-265). The behaviour is live. Filing it because it was almost certainly not intended — and because, having measured it, the accidental behaviour may well be the one we want to keep. Either way it should be a decision.

## What changed

Before #1216, `LandingHero.astro` did:

```ts
const heroSrc = heroImage ? thumbnailPath(heroImage) : null; // the original, animated
```

It now does `landingHeroImage(...)`, which falls through to `getStillImageUrl(url, 1280)` when the asset has no generated copy. That URL carries `anim=false`, so an animated WebP hero renders as **a single frozen frame**.

The workflow *detail* hero does the same still-swap but then swaps the animation back in after `load` on viewports >= 1024 px, honouring `prefers-reduced-motion` (`ThumbnailDisplay.astro`, `WIDE_VIEWPORT`). `LandingHero` got no counterpart, so it is frozen on **every** viewport, desktop included.

#1216 names the mobile detail-hero still as "the one deliberate product change", which is what makes this look unintended.

## Blast radius — smaller than it first looks

Resolved every route locally through the repo's own `heroTemplateFor` / `deriveModelGroups`, then checked all 36 candidates against production. **36 predicted, 36 confirmed, 0 disagreements.**

| | routes |
| --- | ---: |
| Routes using `LandingHero` (17 use-case + 80 model) | 97 |
| Render a `` hero — untouched | 25 |
| Render an `` still | 72 |
| → resolves to a generated `media.comfy.org` JPG — unaffected | 36 |
| → resolves to a `cdn-cgi/image/...anim=false` transform | 36 |
| → **of which the original is animated → FROZEN** | **27** |
| original is a static WebP (transform is cosmetic) | 7 |

**27 routes, 26 unique assets.** Only **4 are indexable**: `/workflows/use-cases/ai-image-to-video`, and the `kling`, `hunyuan3d`, `veo` model pages. The other 23 are `noindex` bare grids.

The 36 generated-copy heroes lose nothing by construction: `encode-images.mjs` writes `skip: 'animated'` for animated sources, so nothing animated ever entered `hub-media-images.json`.

Proof the animation is real, by walking the WebP chunks of the originals:

- `/workflows/model/kling` → `2c714186….webp` — **45 `ANMF` frames, 3000 ms, infinite loop**
- `/workflows/use-cases/ai-image-to-video` → `4c49ebf0….webp` — **52 frames, 3467 ms, infinite loop**
- `/workflows/model/svd` → `8be20e78….webp` — **27 frames, 2700 ms, infinite loop**

## The awkward part: the accident is a big win

| route | original animated WebP | `anim=false` transform | ratio |
| --- | ---: | ---: | ---: |
| `use-cases/ai-image-to-video` | 1,912,388 | 15,694 | 121.9× |
| `model/kling` | 1,327,478 | 12,920 | 102.7× |
| `model/openai` | 964,292 | 10,926 | 88.3× |
| `model/svd` | 740,588 | 16,523 | 44.8× |
| `model/veo` | 525,488 | 10,727 | 49.0× |
| `model/hunyuan3d` | 485,348 | 6,988 | 69.5× |

Across all 26 affected assets: **28.47 MB → 289 KB**, averaging 1,121 KB → 11.1 KB, **100.9×**. This is the LCP element on those pages. Restoring the animation naively puts ~1.1 MB back on the critical path of each — the exact defect #1216 existed to remove.

## The decision

1. **Keep the still.** Ratify it, and say so in `LandingHero.astro` so the next reader does not "fix" it back. Cheapest, and the numbers support it.
2. **Restore the animation properly** — port `ThumbnailDisplay.astro`'s pattern: paint the still, swap the animation in after `load`, gated at >= 1024 px and on `prefers-reduced-motion`. First paint stays ~11 KB and the ~1.1 MB is deferred past load. ~20 lines, one file.
3. **Restore it naively** — drop the `anim=false` path in `landingHeroImage`. Not recommended: it hands back the full cost on the LCP element.

My read is (1) or (2), and (1) unless someone wants the motion on those four indexable pages specifically.

## Unrelated bug found while checking

`/workflows/model/chronoedit` and `/workflows/model/nvidia` both render `b9baf67c-a161-48ca-bcf3-bd1c22a788a5.webp`, and **both the origin asset and the transform 404** — those two heroes are broken images today. Predates #1216 (`hubImageFor` returns null for it too), so it is catalog staleness, not a regression. Happy to split it out if useful.

_{Filed while reviewing #1216. Route resolution used the repo's own modules; production figures fetched from comfy.org.}

Start by reading LandingHero.astro and compare its image handling with ThumbnailDisplay.astro and the WIDE_VIEWPORT behavior described in the issue. Confirm the affected routes and animated-source cases using heroTemplateFor and deriveModelGroups. Done means choosing and documenting the still behavior, or implementing the deferred animation behavior with the stated viewport and reduced-motion constraints.

Written by the indexing model from the issue text.