docs: registrar migracao do web e investigacao do whitelist

docs/operacao/pendencias.md

@@ -238,8 +238,9 @@ A correção registrada em ["GitOps com tag mutável"](#gitops-com-tag-mutavel-n
 
 Mecanismo final: [Argo CD Image Updater](https://argocd-image-updater.readthedocs.io/) instalado como componente de foundation, aplicando a atualização direto na `Application` (`write-back-method: argocd`, sem commit, sem PR), com webhook do GHCR configurado pra reduzir o delay do polling padrão a segundos. Detalhe completo, incluindo a análise de segurança do endpoint exposto, em [Rollout de imagens](../arquitetura/rollout-de-imagens.md).
 
-- [x] **`docs` e `management-service` migrados**: anotações na `Application`, `ImageUpdater` CR único cobrindo `namePattern: "ladesa-ro-*"`.
-- [ ] **`web` e `authentication-service` ainda não migrados**: mesmas anotações a replicar, nenhuma peça de infraestrutura nova necessária (o `ImageUpdater` CR já cobre qualquer satélite `ladesa-ro-*` novo).
+- [x] **`docs` e `management-service` migrados**: anotações na `Application`, `ImageUpdater` CR único cobrindo `namePattern: "ladesa-ro-*"`. Confirmado ao vivo em 2026-08-28: `application.deployment.image.digest` aplicado via parâmetro Helm nos 3 satélites (`docs`, `api`, `timetable-worker`).
+- [x] **`web` migrado**: mesmas anotações, PR [web#790](https://github.com/ladesa-ro/web/pull/790).
+- [ ] **`authentication-service` ainda não migrado**: mesmas anotações a replicar, nenhuma peça de infraestrutura nova necessária (o `ImageUpdater` CR já cobre qualquer satélite `ladesa-ro-*` novo).
 - [ ] **Webhook de organização no GitHub ainda não criado**: token `gh` local não tinha o escopo `admin:org_hook`; pedido de elevação (`gh auth refresh -s admin:org_hook`) expirou sem aprovação a tempo. Falta: aprovar o fluxo de dispositivo e rodar a criação do webhook (evento `package`, URL `https://image-updater.ladesa.com.br/webhook?type=ghcr.io`). Até lá, o Image Updater funciona só por polling (padrão do controller, tipicamente ~2min).
 - [x] **Webhook de organização criado**: id `671516711`, evento `package`, `active: true`.
 - [x] **Projeto `foundation-image-updater-w0cw` criado no Infisical, chave `webhook.ghcr-secret` registrada em `prod`**.
@@ -257,4 +258,5 @@ Diferente do webhook do GHCR (que acorda o Image Updater), este é pro próprio
 Achado ao investigar por que o Image Updater não estava atualizando `docs`/`api`/`timetable-worker` apesar das anotações e do PR #6 (fix de `watch.namespaces`) já mergeados: a `Application foundation-image-updater` estava presa em `OutOfSync`/`Failed` desde a instalação, erro `resource argocd-image-updater.argoproj.io:ImageUpdater is not permitted in project ladesa`. Causa: `argocd/root/project.yaml` nunca ganhou `ImageUpdater` no `namespaceResourceWhitelist` quando o componente foi instalado. O `ImageUpdater` CR nunca sincronizou, e o pod, apesar de `Running`, nunca aplicou o `watch.namespaces=argocd` do PR #6, log mostrando `"Watching controller namespace only"` desde o dia da instalação.
 
 - [x] **Corrigido**: PR [#10](https://github.com/ladesa-ro/infrastructure/pull/10), `namespaceResourceWhitelist` liberado, aplicado direto no cluster (`kubectl apply`) pra desbloquear na hora. `Application` confirmada `Synced`, pod novo já loga `"Watching specific namespaces" namespaces=argocd`.
-- [x] **Anomalia resolvida, causa era outra**: o diagnóstico anterior (controller "não listando" as 3 apps) estava errado, era o nível de log `info` escondendo as linhas de debug e mostrando só o resumo final, que por coincidência também dizia "3". Subindo pra `log.level: debug` de verdade (via `values.yaml`, PR [#10](https://github.com/ladesa-ro/infrastructure/pull/10)) apareceu a causa real: `"Image '...' seems not to be live in this application, skipping"`. Isso é um bug conhecido do próprio Argo CD (`Application.status.summary.images` vazio pra toda `Application` do cluster, não só as 3), [argoproj/argo-cd#27861](https://github.com/argoproj/argo-cd/issues/27861). Mitigado com a anotação `<alias>.force-update: "true"` em `docs`/`api`/`timetable-worker` (PRs [docs#15](https://github.com/ladesa-ro/docs/pull/15), [management-service#1101](https://github.com/ladesa-ro/management-service/pull/1101)). Detalhe completo em [Rollout de imagens](../arquitetura/rollout-de-imagens.md#dois-bugs-reais-achados-ao-vivo-depois-do-deploy-2026-08-28). `log.level` revertido pra `info` depois do diagnóstico (PR [#10](https://github.com/ladesa-ro/infrastructure/pull/10) já mergeada com o valor de debug; revertido em PR separada).
+- [x] **Anomalia resolvida, causa era outra**: o diagnóstico anterior (controller "não listando" as 3 apps) estava errado, era o nível de log `info` escondendo as linhas de debug e mostrando só o resumo final, que por coincidência também dizia "3". Subindo pra `log.level: debug` de verdade (via `values.yaml`, PR [#10](https://github.com/ladesa-ro/infrastructure/pull/10)) apareceu a causa real: `"Image '...' seems not to be live in this application, skipping"`. Isso é um bug conhecido do próprio Argo CD (`Application.status.summary.images` vazio pra toda `Application` do cluster, não só as 3), [argoproj/argo-cd#27861](https://github.com/argoproj/argo-cd/issues/27861). Mitigado com a anotação `<alias>.force-update: "true"` em `docs`/`api`/`timetable-worker`/`web` (PRs [docs#15](https://github.com/ladesa-ro/docs/pull/15), [management-service#1101](https://github.com/ladesa-ro/management-service/pull/1101), [web#790](https://github.com/ladesa-ro/web/pull/790)). Faltava ainda a tag explícita (`:development`) na anotação `image-list`, sem ela o `update-strategy: digest` não tem versão pra ancorar a resolução do digest, corrigido nos mesmos PRs. Detalhe completo em [Rollout de imagens](../arquitetura/rollout-de-imagens.md#dois-bugs-reais-achados-ao-vivo-depois-do-deploy-2026-08-28). `log.level` revertido pra `info` depois do diagnóstico (PR [#10](https://github.com/ladesa-ro/infrastructure/pull/10) já mergeada com o valor de debug; revertido em PR separada). Confirmado ao vivo funcionando de ponta a ponta pros 3 satélites (`application.deployment.image.digest` aplicado via parâmetro Helm).
+- [ ] **`AppProject ladesa` perdeu o whitelist do `ImageUpdater` de novo, sem causa raiz confirmada**: depois de corrigido pelo PR #10 e aplicado com sucesso pelo `self-pull-timer` (confirmado no log do `ansible-pull` às 15:31:46, diff aplicado corretamente), o campo sumiu de novo da `AppProject` viva por volta de 15:57, travando o `foundation-image-updater` de novo com o mesmo erro `is not permitted in project ladesa`. Investigado: sem segunda definição do `AppProject` em outro arquivo, sem redefinição via `configs.projects` no Helm values do Argo CD, sem outra execução do `ansible-pull` nesse intervalo. O histórico de `managedFields` que poderia mostrar quem escreveu por último foi apagado sem querer pelo próprio `kubectl apply` (client-side) usado pra corrigir na hora, tanto o meu quanto o do Ansible usam client-side apply, que sempre colapsa pra um único manager `kubectl-client-side-apply`. Corrigido de novo manualmente. Se acontecer de novo, capturar `kubectl get appproject ladesa -o yaml` (incluindo `managedFields`) **antes** de corrigir, pra não perder o rastro de novo.