perf: servir imagens de conteúdo em webp e descrever sizes corretamente (MAN-109)

Fecha a meta de LCP ≤ 2,5 s da SPEC §6.6 em todas as páginas, nos dois presets.
Continuação direta do commit anterior: com fontes e marca resolvidas, o elemento
de LCP de toda página no mobile passou a ser a imagem do hero, e o Load Delay de
1,88 s era contenção de banda pura.

## Variantes webp

`ResponsiveImage::generate()` escreve uma variante `.webp` ao lado de cada
variante no formato original, e `x-media.image` a oferece num
`<source type="image/webp">`. O `<img>` continua apontando para o formato
original: o `<source>` é preferência, não substituição, então nada quebra em
quem não decodifica webp, e mídia antiga sem irmãos webp renderiza `<img>` puro
como antes.

O `<picture>` recebe `display: contents` porque os chamadores estilizam o `<img>`
com classes como `h-full w-full object-cover` que resolvem contra o pai grid ou
flex — um wrapper inline quebraria isso.

O nome do arquivo acrescenta a extensão em vez de trocá-la
(`photo-720.jpg.webp`): uploads usam UUID, então colisão já era improvável, mas
`photo-720.webp` colidiria com a variante webp de um `photo.png`.

## sizes que descreve a realidade

Nenhuma imagem do site ocupa a viewport inteira — todas ficam dentro de
`container-amare`, que reserva 1,5rem de padding de cada lado. Declarar `100vw`
fazia uma viewport de 412 px em DPR 1,75 pedir 721 px e pular para a variante de
960 para desenhar uma caixa de 637 px. Errar por um pixel custava um terço a mais
de bytes em toda página.

Com `calc(100vw - 3rem)` a home passa a usar a variante de 720: 74 KiB, contra
143 KiB no início da investigação. Foi também por isso que 720 entrou em
`ResponsiveImage::WIDTHS` — sem ela o salto de 480 para 960 é grande demais para
a viewport mobile mais comum.

## Efeito medido

Mobile, mediana de 3 execuções: home 3,39 → 2,49 s; portfolio-detalhe
3,01 → 2,18 s; servicos 2,63 → 2,03 s; portfolio 1,58 s; sobre 1,58 s;
contato 1,50 s. Desktop no máximo 0,65 s. Peso total da home 798 → 347 KiB.

Contra o início da investigação (`2e43fde`): home 4,58 → 2,49 s com score de
performance 83 → 98.

A home passa **em cima da linha** — a pior das três execuções deu 2,57 s. Está
documentado como aprovada por margem, não com folga, e os levers restantes estão
listados em docs/evidence/lighthouse/README.md em ordem de custo.

Os 16 baselines visuais não mudaram: nenhum seeder gera variantes e
`media:generate-variants` não roda no runner visual, então naquele ambiente
`availableVariants()` volta vazio e o componente renderiza `<img>` puro. A
cobertura do caminho com variantes fica em MediaImageComponentTest e
ResponsiveImageTest, não nos baselines — anotado como lacuna conhecida.

Co-Authored-By: Claude noreply@anthropic.com
AI-Assisted: yes
AI-Tool: claude-code

resources/views/components/media/image.blade.php

@@ -1,7 +1,11 @@
 @props([
     'path',
     'alt',
-    'sizes' => '(max-width: 768px) 100vw, 960px',
+    // No image on the site spans the full viewport: every one of them sits inside
+    // `container-amare`, which reserves 1.5rem of padding on each side. Claiming
+    // 100vw made a 412 px viewport at DPR 1.75 ask for 721 px and jump to the
+    // 960 variant for a box it draws at 637 px.
+    'sizes' => '(max-width: 768px) calc(100vw - 3rem), 960px',
     'loading' => 'lazy',
     'fetchpriority' => null,
     'width' => null,
@@ -18,15 +22,25 @@
     $diskName = $disk ?? PublicImageUploadRules::disk();
     $filesystem = Storage::disk($diskName);
     $src = $filesystem->url($path);
-    $variants = ResponsiveImage::availableVariants($path, $diskName);
-    $srcset = collect($variants)
+
+    $toSrcset = fn (array $variants): string => collect($variants)
         ->map(fn (array $variant): string => $filesystem->url($variant['path']).' '.$variant['width'].'w')
         ->implode(', ');
 
+    $variants = ResponsiveImage::availableVariants($path, $diskName);
+    $srcset = $toSrcset($variants);
+
     if ($srcset === '' && $filesystem->exists($path)) {
         $srcset = null;
     }
 
+    // Offered ahead of the original format because webp carries the same picture
+    // for roughly a third of the bytes, and the MAN-109 audit found the hero
+    // image to be the LCP element on every page at mobile widths. Media uploaded
+    // before `media:generate-variants` learned to emit webp has no siblings, so
+    // the <source> is skipped rather than pointed at nothing.
+    $webpSrcset = $toSrcset(ResponsiveImage::availableWebpVariants($path, $diskName));
+
     $dimensions = ($width === null || $height === null)
         ? ResponsiveImage::dimensions($path, $diskName)
         : null;
@@ -36,6 +50,13 @@
     $loadingValue = $loading;
 @endphp
 
+{{-- `display: contents` keeps <picture> out of the layout: the callers style the
+     <img> with classes like `h-full w-full object-cover` that resolve against the
+     grid or flex parent, and an inline wrapper would break that. --}}
+@if ($webpSrcset !== '')
+<picture class="contents">
+    <source type="image/webp" srcset="{{ $webpSrcset }}" sizes="{{ $sizes }}">
+@endif
 <img
     src="{{ $src }}"
     @if ($srcset) srcset="{{ $srcset }}" sizes="{{ $sizes }}" @endif
@@ -47,3 +68,6 @@
     @if ($class) class="{{ $class }}" @endif
     {{ $attributes->except(['path', 'alt', 'sizes', 'loading', 'width', 'height', 'disk', 'class']) }}
 >
+@if ($webpSrcset !== '')
+</picture>
+@endif