Feature/eventos:Escrita - POST/PUT/DELETE

[vitorhugomoraes2486]

Endpoints implementados:

• POST /api/v2/expedicoes/:expedicaoId/eventos
• PUT /api/v2/eventos/:eventoId
• DELETE /api/v2/eventos/:eventoId

Construção PUT:

• O PUT do agregado evento + ficha de coleta; trocar tipo de COLETA para DIARIO apaga a linha em eventos_coletas; o caminho inverso cria a linha; manter o tipo e enviar coleta faz upsert (evento_id é PK);
• Reaproveitamento de Evento.create() para validar o PUT.

Tratamento de erros:

• CheckViolationError: sinaliza rejeição do Postgres por violr uma regra eventos_tipo_check. Só aceita tipo = DIARIO ou COLETA;
• ForeignKeyViolationError: expedicao_id enviado não existe no banco, respondido com status 404;
• UnprocessableEntityError : a classe que faz o servidor responder com o status 422.

Pontos marcados nos controllers para quando a autenticação for implementada.

[EduTiyo]

Revisão em duas frentes (Standards e Spec) da escrita de Eventos. A transação do PUT do agregado (trocar tipo COLETA↔DIARIO apagando/criando eventos_coletas, upsert quando o tipo não muda) está correta e dentro de uma transação só, e o mapeamento CHECK→422 foi rastreado ponta a ponta e funciona. Peço mudança por um motivo concreto: dois testes de integração deixam dados vazarem se a asserção falhar, violando a regra do próprio test/integration/README.md. O resto são observações de manutenibilidade, não bloqueantes.

[EduTiyo]

[Standards] Cleanup sem finally. Este teste (e o próximo, 'POST cria um evento COLETA com a ficha') faz o expect/toMatchObject e só depois await knex('eventos')...delete(), sem try/finally. Se a asserção falhar, a linha fica no banco — exatamente o que test/integration/README.md pede pra evitar ("Limpe os dados inseridos em um bloco finally, para que a limpeza rode mesmo se a asserção falhar"). Os testes de PUT/DELETE logo abaixo (ex: linha 117) já fazem certo — só replicar o padrão aqui.

[EduTiyo]

[Standards] Assimetria de estilo (não-bloqueante). Diferente de CriarEventoController/AtualizarEventoController, aqui qualquer left() vira 500 direto, sem checar instanceof CheckViolationError/ForeignKeyViolationError. Hoje é inofensivo — delete() por id não produz esses erros — mas se um novo tipo de erro for adicionado ao pg-error.ts no futuro, é fácil esquecer de replicar aqui também.

[EduTiyo]

[Standards] Duplicated Code (smell). CAMPOS_DA_FICHA, isPlainObject e parseColeta estão copiados quase verbatim aqui, em AtualizarEventoController.ts (linha ~110) e uma terceira vez em EventoCollectionKnexAdapter.ts. Os três commits de fixup desta branch (0196a7b/432d71a/b391863) já mostram esse padrão sendo remendado separadamente em cada arquivo — sinal de que a duplicação vai continuar divergindo. Vale extrair para um módulo compartilhado antes que aconteça de novo.

[EduTiyo]

[Spec] Nota, não bloqueio. O combinado dizia "a regra de coerência existe em Evento.create(), mas o update precisa da sua própria". O que foi feito aqui reaproveita Evento.create() sobre o estado final mesclado, em vez de escrever uma regra separada — satisfaz a intenção (o estado final é validado antes de persistir) por DRY, mas diverge da letra do combinado. Só peço confirmação de que isso foi uma decisão consciente, não um corte de escopo.