fix(import): preserve attachment content when fixture embedding fails

[seonghobae]

Finding

CodeRabbit review of #1696 exposed a pre-existing data-integrity defect in backend/import_fixtures.py that is outside the retained exception-redaction scope.

Inside the attachment loop, generate_fixture_embedding(...) is called before Attachment(...) is appended to email_obj.attachments. If embedding generation raises, the current except path logs the failure and continues. The enclosing email object is then committed, so the failed attachment is silently omitted even though its parsed filename/content/MIME data was already available.

This is not caused by #1696. #1696 is being narrowed back to the public tool error-response boundary so this independent aggregate mutation is not hidden inside a generated security sweep.

Required repair

Treat attachment persistence and embedding enrichment as separate outcomes. On embedding failure, either:

• persist the attachment with embedding=None while preserving its parsed content and provenance, if that is the intended aggregate contract; or
• fail/roll back the entire email import if an attachment embedding is mandatory.

Do not silently commit an Email aggregate with an attachment removed solely because derived embedding generation failed.

Add regression coverage that forces attachment embedding generation to fail and verifies the chosen invariant at commit time. Also verify transaction behavior: no long-lived transaction should remain open across remote/model work, and no partial-write state may be presented as a successful complete import.

Acceptance boundary

• explicit Email/Attachment aggregate invariant documented in code/doctoring;
• deterministic test for attachment-embedding failure;
• no silent attachment loss;
• commit/rollback behavior verified;
• real PostgreSQL acceptance when the repository CI foundation permits it;
• no dependency/security-gate suppression or unrelated exception-redaction changes.

Refs #1696 review finding on backend/import_fixtures.py.

[seonghobae]

Repair lane opened as Draft PR #1699 at exact 98513741056aadbaf88347b9ed6e44fd857e2dc4. The patch preserves parsed attachment content with embedding=None on enrichment failure and moves all embedding work ahead of the first database statement so model I/O does not sit inside the fixture import transaction. Keep this issue open until #1699 reaches exact-head GREEN/review and merges normally.

[seonghobae]

Canonical repair topology changed after overlap verification. Direct-develop #1699 contains valid attachment/transaction/PostgreSQL work but also edits backend/import_fixtures.py, which #1612 already owns for exception redaction; relative to #1612, #1699 restores raw exception interpolation. I therefore froze #1699 as predecessor and created ordinary stacked successor #1701 on exact #1612. #1701 exact 23ab3653543240c9c194e98530bb793d037489bc / tree 525d4c42800f5ac2912385d1b18aff5bd83a19f9 preserves #1612's non-secret failure logs while inheriting #1699's duplicate-before-enrichment, transaction release, post-enrichment duplicate guard, attachment embedding=None persistence, tests, doctoring, and real PostgreSQL persistence/cascade acceptance source. Keep #1697 open until #1701 or an integrated descendant receives actual PostgreSQL/migration/security evidence and normally lands; do not merge #1699 independently.