feat(nogglesrails): auto-link propdates to rail pages

[mtlouzada]

Summary

• Cada rail financiado por uma proposta da Base agora exibe automaticamente os propdates onchain daquela proposta numa seção "Updates", em vez de texto escrito à mão.
• A ligação é feita por um novo campo proposalNumber nos 9 rails financiados por propostas da Base (validados contra produção).
• A seção carrega no client reusando o endpoint /api/propdates/enriched (já cacheado, revalidate=300 + CDN), então a página do rail continua estática (●) — sem custo novo de SSR/ISR.

Changes

• src/content/nogglesrails.ts — novo campo opcional proposalNumber + preenchido nos 9 rails de proposta Base (4, 20, 25, 33, 41, 63, 68, 73, 89). Rails de Snapshot/Nouns/orgânicos ficam sem o campo (no-op).
• src/components/nogglesrails/RailPropdates.tsx (novo) — client component que busca /api/propdates/enriched, casa por proposalNumber e renderiza com o PropdateCard existente. Retorna null quando não há propdate.
• src/app/[locale]/nogglesrails/[slug]/page.tsx — renderiza a seção entre a descrição e a galeria, só quando há proposalNumber.
• messages/{en,pt-br}/installations.json — strings novas (Updates / Atualizações).

Test plan

• Abrir no preview: /nogglesrails/rio-de-janeiro-delta → deve mostrar a seção "Updates" com os propdates reais da proposta refactor: improve proposal interaction components with shadcn consistency #20.
• Abrir /nogglesrails/silverado (proposta Nouns, sem propdate na Base) → NÃO deve mostrar a seção (gating correto).
• Versão PT: /pt-br/nogglesrails/rio-de-janeiro-delta → seção "Atualizações".
• Conferir layout no mobile.

⚠️ Nota pra quem revisar: rodando localmente com o .env de teste, nenhum rail mostra a seção (as propostas de teste não correspondem a rails). Testar no preview/produção, que usam o DAO real da Base — lá a #20 já tem 3 propdates.

Generated with Claude Code

[vercel]

@mtlouzada is attempting to deploy a commit to the r4to's projects Team on Vercel.

A member of the Team first needs to authorize it.

[r4topunk]

Automated multi-agent review — approve with one nit

Reviewed in an isolated worktree by parallel Opus reviewers with adversarial verification. The design is sound: the RailPropdates client component reuses the already-cached /api/propdates/enriched endpoint so rail pages stay static (no new SSR/ISR cost), proposal↔feed matching is correct, and the new strings are in both locales with the right glossary (proposta). One confirmed nit:

🟠 Medium — "View all updates" deep-link lands on the wrong tab

allUpdatesHref is built as /proposals/base/${proposalNumber}?tab=propdates (src/components/nogglesrails/RailPropdates.tsx:42), but the destination renders uncontrolled Radix tabs — <Tabs defaultValue="details"> (src/components/proposals/detail/ProposalDetail.tsx:293) — and nothing in the detail tree or the route reads a tab search param. So the query string is inert and the user lands on Details, not Propdates, despite the "View all updates" label.

Fix (pick one):

• Wire the tab to the URL: read useSearchParams() in ProposalDetail and make <Tabs value=... onValueChange=...> controlled, or
• Drop the ?tab=propdates param and link to an #propdates anchor / the propdates tab route if one exists.

[mtlouzada]

Nit fixed in 1b5b814. ProposalDetail now reads ?tab= and honors it once the target tab is revealed post-mount (plain defaultValue would render blank before the data loads); unknown values fall back to Details. Added an e2e regression spec for the deep link — 3/3 passing locally, and verified manually.