docs: registrar a dependência do deploy e corrigir os commits nas evidências

Três correções de honestidade nos artefatos de medição.

O campo `Commit:` era gravado com o HEAD do momento da coleta, que é sempre
anterior ao commit que contém as mudanças medidas — as duas passadas pós-correção
diziam `2e43fde` e `65919d4` quando as árvores medidas viraram `65919d4` e
`9ab2beb`. Corrigido à mão nos dois arquivos, e o script passa a marcar
`+alterações não commitadas` quando a árvore está suja, para o artefato não voltar
a afirmar o que não é.

O ganho das imagens não aparece em staging nem em produção antes de
`media:generate-variants` rodar: lá o disco é `r2` e as variantes webp e a largura
720 ainda não existem para a mídia publicada. O serviço `migrate` do
docker-compose.deploy.yml roda o comando sem condição a cada deploy e ele
regenera mesmo quando já há variantes, então o primeiro deploy resolve — mas
estava implícito e agora está escrito.

E o custo que as variantes webp introduzem no lado servidor está registrado com o
número certo: `x-media.image` faz 8 `exists()` por imagem no lugar de 3, o que em
`r2` são ~9 round trips remotos por imagem e ~36 na home. Isso agrava a hipótese
não validada de TTFB em staging em vez de melhorá-la, e promove o cache desses
metadados a item mais urgente da lista.

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

docs/evidence/lighthouse/README.md

@@ -137,6 +137,26 @@ Decomposição final do LCP da home no mobile:
 | Load Time | 0,10 s |
 | Render Delay | 0,69 s |
 
+## O ganho de imagem só aparece depois do deploy regenerar as variantes
+
+Toda a medição acima usou `FILESYSTEM_DISK=local`. Em staging e produção o disco
+é `r2`, e lá as variantes `.webp` e a largura 720 **ainda não existem** para a
+mídia já publicada. Até `media:generate-variants` rodar, `availableWebpVariants()`
+volta vazio, o `<source>` é omitido e o `srcset` do formato original perde a
+entrada de 720w — ou seja, nenhum dos dois ganhos de imagem aparece.
+
+O serviço `migrate` do `docker-compose.deploy.yml` roda
+`php artisan media:generate-variants` sem condição a cada deploy, depois de
+`migrate` e do seed, e o comando só pula um caminho quando o arquivo original não
+existe (`MediaGenerateVariantsCommand`) — regenera mesmo quando já há variantes.
+Então o primeiro deploy desta branch produz as variantes novas por conta própria.
+
+Enquanto isso não acontece, há um custo sem contrapartida: `x-media.image` faz
+agora **8 chamadas `exists()` por imagem** (4 larguras × 2 formatos) contra o
+object store, no lugar de 3. Na home são ~32 round trips remotos por request em
+vez de ~12. Isso agrava a hipótese não validada abaixo em vez de melhorá-la, e é
+mais um motivo para cachear esses metadados.
+
 ## Se a home precisar de mais folga
 
 O Load Delay de 1,24 s ainda é contenção: as três capas do portfólio somam
@@ -172,12 +192,14 @@ minutos auditando páginas de bloqueio.
 Duas hipóteses seguem **não validadas** porque só existem com
 `FILESYSTEM_DISK=r2`, que é configuração de staging e produção:
 
-- `x-media.image` chama `ResponsiveImage::availableVariants()` (3 `exists()`) e
-  `ResponsiveImage::dimensions()` (que baixa o arquivo inteiro) a cada render,
-  sem cache. No disco `local` são leituras de filesystem; no `r2` são ~4 round
-  trips remotos por imagem no lado servidor, ~16 na home. Teste discriminante:
-  comparar o TTFB de `/contato` (zero imagens) com o de `/portfolio` (N imagens).
-  Se o TTFB escalar com a contagem de imagens, está confirmado.
+- `x-media.image` chama `ResponsiveImage::availableVariants()`,
+  `availableWebpVariants()` (8 `exists()` somados) e `ResponsiveImage::dimensions()`
+  (que baixa o arquivo inteiro) a cada render, sem cache. No disco `local` são
+  leituras de filesystem; no `r2` são ~9 round trips remotos por imagem no lado
+  servidor, ~36 na home. Teste discriminante: comparar o TTFB de `/contato`
+  (zero imagens) com o de `/portfolio` (N imagens). Se o TTFB escalar com a
+  contagem de imagens, está confirmado. **Este é o item mais urgente da lista**,
+  porque as variantes webp multiplicaram o número de chamadas.
 - A mídia vem de `R2_URL`, uma origem cross-origin, e não há `preconnect` no
   `<head>` — DNS e TLS entram antes do LCP.