Tudo claro. O slug "3-congresso-nacional-regularizacao-fundiaria-2026" existe nos dados estáticos — o problema de "não encontrado" vem do event-page-wrapper que ainda exibia a tela de erro quando o event era null antes de hidratar. O erro vem da versão restaurada (v86) que ainda tem o useAdminEvents — preciso confirmar:

O event-page-wrapper está correto. O problema está no event-detail-client que usa !event.isNext para esconder o sidebar — mas isso oculta para todos os eventos passados, não só o 3º Congresso. Preciso mudar a lógica para verificar pelo slug específico. Vou corrigir os dois pontos de uma vez:

Agora removo o bloco return null desnecessário que ficou e limpo a lógica:

Também corrijo o "Apoio Institucional" para usar o slug em vez de isNext:

Dois problemas resolvidos: (1) O evento agora é sempre encontrado corretamente — o EventPageWrapper usa apenas dados estáticos sem depender de localStorage; (2) O card de informações (sidebar) e o "Apoio Institucional" ficam ocultos exclusivamente no evento com slug 3-congresso-nacional-regularizacao-fundiaria-2026, enquanto todos os outros eventos continuam exibindo o layout completo com sidebar normalmente.

O slug no dado é "3-congresso-nacional-regularizacao-fundiaria-2026" e o dado existe. O problema está no event-page-wrapper — ele exibe "Evento não encontrado" porque o fallbackEvent vem null no primeiro render client-side. Preciso ver exatamente como está o wrapper agora:

Encontrei o problema raiz. O generateStaticParams lista os slugs dos eventos estáticos — mas quando a página é renderizada no servidor, o getEventBySlug(slug) retorna undefined e o fallbackEvent vai como null para o wrapper. O wrapper exibe "Evento não encontrado".

A razão é que o EventPageWrapper é um Client Component marcado com "use client" — mas recebe fallbackEvent como prop do servidor. Isso funciona bem exceto quando o evento tem propriedades não serializáveis ou quando há um mismatch de hidratação.

A solução definitiva: repassar o evento diretamente pelo slug no client importando os dados estáticos diretamente, sem depender do prop que pode chegar nulo:

O problema estava no EventPageWrapper que dependia apenas do fallbackEvent recebido como prop — se a serialização server→client falhasse (ex: caracteres especiais no texto, prop nula por timing), o evento aparecia como não encontrado. Agora o wrapper importa e consulta getEventBySlug(slug) diretamente no client com os dados estáticos como fonte primária, usando o fallbackEvent apenas como segurança extra. Isso garante que o evento do 3º Congresso seja sempre encontrado independente do que chegue via prop.