fix(mail): relatorios DMARC nao mostravam o clipe de anexo

has_attachments so era definido para mensagens multipart. Um relatorio
agregado DMARC do Google e de parte unica: o corpo E o anexo, um
application/zip sem qualquer parte de texto. Ficava guardado como nao tendo
anexos, ao lado dos relatorios TLS-RPT do mesmo remetente e na mesma pasta,
que trazem uma linha de texto e por isso sao multipart/mixed e apareciam
marcados.

A regra passa a olhar tambem para a parte de topo: uma disposicao explicita
decide (um .txt enviado como a mensagem inteira e anexo, uma parte inline nao
e), e sem ela conta como anexo tudo o que nao seja texto nem multipart -- um
zip, um PDF, uma mensagem reencaminhada.

As mensagens ja guardadas mantinham a marca antiga, e sao justamente aquelas
que o utilizador esta a olhar. Ha um backfill que as re-le uma vez, em segundo
plano, sem atrasar o arranque. So examina as que estao marcadas como sem
anexos: a regra antiga nunca inventou um anexo que nao existisse, portanto uma
marca verdadeira nao precisa de segunda opiniao e a varredura fica do tamanho
do defeito. A tabela backfills guarda o marcador para nao repetir a cada
arranque.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

migrations/0011_backfill_markers.up.sql

@@ -0,0 +1,12 @@
+-- Records one-shot data repairs so they run once rather than on every start.
+--
+-- The first user is the attachment flag: has_attachments was only ever set for
+-- multipart messages, so a single-part attachment - a DMARC aggregate report,
+-- whose whole body is a zip - was stored as having none. The fix corrects new
+-- deliveries; the messages already filed need re-reading, and re-reading every
+-- message on every boot is not something to do forever.
+CREATE TABLE IF NOT EXISTS backfills (
+    name         VARCHAR(64) PRIMARY KEY,
+    completed_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    detail       TEXT
+);