feat: add to calendar (google calendar button + .ics link for other apps)

[ppadron]

[brunomartins84]

@ppadron

Opa, valeu demais pelo trabalho aqui! 🤘 Antes de tudo: o src/lib/ics.ts ficou muito bem feito — escape conforme a RFC 5545, folding em 75 octetos sem cortar caractere multi-byte, evento de dia inteiro com DTEND exclusivo, UID estável. Isso é o tipo de coisa que quase todo mundo erra na primeira, e você acertou.

Só que eu queria repensar o desenho antes de seguir, e acho que o ponto é o recorte: hoje a feature assina todos os shows de um estado, e eu acho que faz mais sentido ser por show.

O motivo principal são os números. Temos 360 shows futuros cadastrados, e 155 deles são de SP — só nos próximos 30 dias são 72 shows em SP. Ou seja, quem assinar o feed do estado recebe ~2,4 eventos por dia despejados na agenda pessoal, no meio de reunião de trabalho e consulta médica. É o caminho mais curto pra pessoa desassinar em uma semana — e o problema é pior justamente no estado onde temos mais público.

Segundo motivo: "me avise quando tiver show novo" já está resolvido pelo push ("Ativar avisos de shows", logo acima na home). O feed por estado meio que duplica esse trabalho. O que ninguém resolve hoje é o outro caso: "esse show aqui eu vou, não quero esquecer". Esse é o que eu acho que vale atacar.

Contraproposta: botão "Adicionar ao meu calendário" no cartaz do show (e talvez no card da home), com link do Google Calendar via render?action=TEMPLATE&text=...&dates=... e um /cartaz/<id>.ics estático pra Apple Calendar / Outlook. Reaproveitando o teu ics.ts quase inteiro — o buildEvent já faz o essencial. São arquivos minúsculos e dá pra gerar só pros shows futuros.

Outros pontos que anotei lendo o código, independente do rumo que a gente tomar:

1. UI na home. O botão preto + campo de URL entre o filtro de estados e a busca empurra os cartazes pra baixo. No celular isso custa caro numa tela cujo trabalho é justamente mostrar show.
2. DTSTAMP com a hora do build. Como ele muda a cada build, os .ics saem sempre diferentes mesmo sem mudança de conteúdo. Hoje, build idêntico não gera commit na gh-pages (foi o que aconteceu no upgrade do Astro) — com isso todo rebuild passaria a gerar deploy novo. Considerando que o Pages já nos deu dor de cabeça com deploy falhando, prefiro não aumentar a exposição.
3. Erro do Strapi vira feed parcial silencioso. No [state].ics.ts, se o fetch falha o loop dá break e segue com o que tem: o build passa e publica calendário incompleto, sem ninguém ficar sabendo. Melhor deixar estourar (como o index.astro faz) do que publicar errado.
4. 27 arquivos gerados, incluindo calendários vazios pra estados sem show.

Sobre o print da descrição: aparece localhost:4321 porque foi tirado no dev server — o código monta a URL com window.location.origin, então em produção sai certo. Só vale trocar a imagem pra não confundir quem for revisar depois.

Topa adaptar pro formato por show? Se preferir, eu pego essa parte e você revisa — o grosso do trabalho (o ics.ts) já está feito e é teu.