fix: render admin timestamps in the viewer's timezone (#1041)

[milkway]

Closes #1041.

O bug

Reportado no hugo: a aba Auditoria mostrava tudo 3 horas adiantado.

O banco guarda UTC (correto). O que faltava era conversão na renderização — chrono::DateTime::format imprime o relógio do próprio valor, então um DateTime<Utc> interpolado direto no template sai em UTC. Para quem está em UTC−3, o futuro.

Cinco telas tinham o mesmo defeito: Auditoria, Atividades dos usuários, Aplicações (atualizado em), Credenciais e Usuários. Nas colunas só-data o erro só aparecia entre 21h e meia-noite locais — por isso só a auditoria (com segundos, em eventos recentes) foi notada.

A correção

No cliente, não por configuração de fuso no servidor: box e hugo precisariam ser configurados um a um, e operadores podem estar em fusos diferentes de qualquer forma.

• Cada célula vira <time datetime="…Z" data-rk-time="<padrão>">, com o texto UTC preservado como fallback sem JS.
• Um renderizador no admin/_layout.html reescreve para o fuso do navegador. Os padrões espelham os formatos chrono que substituem (dd/mm/aaaa hh:mm:ss, dd/mm/aaaa hh:mm, dd/mm/aaaa, aaaa-mm-dd) — nenhuma tela muda de forma, só a hora fica certa.
• Hover mostra a data completa com o nome do fuso, no idioma da página.
• Sem strings i18n novas.

De brinde: o renderizador grava data-sort-value (epoch) na célula, consertando a ordenação da coluna de data — o enhancer de tabelas tirava os separadores e lia 29/07/2026 como um número só, ou seja, ordenava por dia do mês.

Verificação ao vivo

Instância local numa máquina em America/Recife (mesmo offset do hugo), Playwright dirigindo o Chrome instalado:

Tela	padrão	UTC no atributo	renderizado
Auditoria	datetime-s	2026-07-29T13:00:00Z	29/07/2026 10:00:00
Aplicações	datetime	2026-07-29T13:00:00Z	29/07/2026 10:00
Usuários	date-iso	2026-07-29T13:00:00Z	2026-07-29
Credenciais	date	2026-07-30T01:00:00Z	29/07/2026

A última linha é o caso de virada de dia: o código antigo mostrava 30/07/2026, um dia inteiro errado. 46 células conferidas nas 5 telas, todas convertidas, nenhuma pulada.

Regressão

• template_lint: um timestamp formatado sem o wrapper <time data-rk-time> quebra o teste.
• template_lint: some o renderizador do layout, quebra também (o par attributo+script é o que faz a coisa funcionar).
• activity_ui: a página renderizada tem que emitir um instante RFC-3339 de verdade no atributo, não o texto pt-BR.

Gate: cargo test verde, cargo clippy --all-targets -- -D warnings limpo, i18n-check OK.

Fora do escopo

• Agendador de cronjobs avalia expressões cron em UTC — jobs disparam fora do horário local esperado #1042 — o agendador avalia cron em UTC (jobs.rs:118); um 0 8 * * * dispara às 05h locais. Mesmo buraco, consequência operacional, e não dá para resolver no navegador. Precisa de decisão de config (server.timezone).
• Timestamps pré-formatados no Rust já rotulados UTC (schedules_ui.rs:114, routes/admin/users.rs:374, routes/admin/mfa.rs:198) — honestos hoje, mas inconsistentes com estas telas; alinhar junto do Agendador de cronjobs avalia expressões cron em UTC — jobs disparam fora do horário local esperado #1042.

Gotcha reconfirmada

Editar só um .html não rebuilda ruscker-admin — o smoke rodou contra o binário velho e o tooltip saiu no idioma errado até eu dar touch no lib.rs. O de sempre, registrado no CLAUDE.md.

🤖 Generated with Claude Code

[milkway]

Auto-review (autor = revisor, então com rigor extra)

Passei o diff procurando o que ele quebra. Três verificações e um achado real.

Achado real, corrigido em 57d8b47: a aba Logs tinha o mesmo bug e escapou do #1041. A varredura da issue procurou chamadas format de chrono nos templates — e o /admin/logs monta o timestamp em JavaScript: pega o instante ISO do stream do tracing, tira a data e o Z, e imprime o HH:MM:SS.mmm que sobra, ou seja, UTC. Três horas adiantado, igualzinho à auditoria. Agora converte para o fuso do viewer mantendo os milissegundos, com o instante UTC bruto no title da célula para quem for correlacionar com o log baixado (esse endpoint é do servidor e continua em UTC, como um arquivo de log deve ser). Campo não-parseável cai no comportamento antigo em vez de esvaziar a coluna. Verificado ao vivo: linha de 17:38:06.973Z renderiza 14:38:06.973.

Verificações que passaram:

• Ordenação. O data-sort-value que eu gravo é lido pelo cellVal do enhancer e passa pelo parseFloat como número — ordena por instante. Na auditoria ele não faz nada (a tabela não tem data-enhance, de propósito: ordenar separaria a linha do seu diff), mas é inofensivo. Onde ele conta é em Aplicações, Usuários e Credenciais, que têm data-enhance.
• Não sobrescrevo nada. Nenhum dos cinco templates emite data-sort-value no servidor.
• Timestamps pré-formatados no Rust (schedules_ui.rs:114, routes/admin/users.rs:374, routes/admin/mfa.rs:198) continuam intactos e rotulados UTC — honestos, mas inconsistentes com estas telas. Alinhar junto do Agendador de cronjobs avalia expressões cron em UTC — jobs disparam fora do horário local esperado #1042, que é quem vai trazer um fuso do lado servidor.

Gate local: clippy -D warnings limpo, i18n OK. O cargo test teve uma falha ambiental, não do diff: ruscker-docker::readiness_wait_honours_configured_timeout estourou 240 s porque o Docker Desktop desta máquina travou (um docker version ficou pendurado >120 s). O teste é de readiness de container; o diff aqui é HTML e testes de ruscker-admin, que ruscker-docker não lê. O mesmo teste passou no CI deste PR e no cargo test completo de antes desta mudança.