test(exporters): fix flaky DOCX byte-comparison tests — compare content not raw bytes

Two tests in test_exporters.py compared raw .docx bytes. A .docx is
a ZIP archive and python-docx stamps the current mtime into every
entry's local file header, so two renders a second apart differ
byte-wise even when the document content is byte-identical.

  * test_export_docx_bytes_unknown_theme_falls_back_to_classic_ats
    asserted `fallback_bytes == classic_bytes` — intermittently
    FAILED across a DOS-timestamp 2-second boundary (~1-in-5;
    surfaced as a byte diff at index ~10, the ZIP last-mod-time
    field).
  * test_export_docx_bytes_themes_produce_different_outputs
    asserted `classic_bytes != neutral_bytes` — never failed, but
    was effectively vacuous: timestamps alone guarantee the bytes
    differ, so it would have passed even if the theme/palette
    switch were completely broken.

Both rewritten to compare EXTRACTED document content via the
existing helpers instead of raw bytes:
  - fallback test: _docx_paragraph_pairs + _docx_run_color_hexes +
    _docx_run_font_names must all be EQUAL (unknown theme renders
    identically to classic_ats).
  - themes test: _docx_run_color_hexes must DIFFER (classic_ats
    warm-brown vs professional_neutral black) — a real palette-
    switch regression guard.

Deterministic now — confirmed stable 5/5 consecutive runs. 32/32
exporter tests green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: LEANDERANTONY

docs/DEVLOG.md

@@ -2799,8 +2799,20 @@ font-assertion tests (classic_ats / professional_neutral) inverted
 to expect Arial-only. 32/32 exporter tests + renderer-fidelity
 runner (OVERALL PASS) green.
 
-Noted but NOT fixed (pre-existing, unrelated):
-`test_export_docx_bytes_unknown_theme_falls_back_to_classic_ats`
-compares raw timestamped `.docx` ZIP bytes — flaky across a
-DOS-timestamp second boundary. Should compare extracted content,
-not raw bytes; worth a separate fix.
+Follow-up fix — flaky DOCX byte-comparison tests. Two tests in
+`test_exporters.py` compared raw `.docx` bytes. A `.docx` is a ZIP
+and python-docx stamps the current mtime into every entry header,
+so two renders a second apart differ byte-wise even with identical
+content:
+  * `test_export_docx_bytes_unknown_theme_falls_back_to_classic_ats`
+    asserted `fallback_bytes == classic_bytes` — intermittently
+    failed across a DOS-timestamp boundary (~1-in-5).
+  * `test_export_docx_bytes_themes_produce_different_outputs`
+    asserted `classic_bytes != neutral_bytes` — never failed, but
+    vacuous: timestamps alone make the bytes differ, so it would
+    pass even if the theme switch were entirely broken.
+Both rewritten to compare EXTRACTED content via the existing
+helpers — `_docx_paragraph_pairs` + `_docx_run_color_hexes` +
+`_docx_run_font_names` (equal for the fallback test, color-set
+differs for the themes test). Deterministic now; confirmed stable
+5/5 consecutive runs. 32/32 exporter tests green.

tests/test_exporters.py

@@ -866,34 +866,48 @@ def test_export_docx_bytes_professional_neutral_uses_black_palette():
 
 
 def test_export_docx_bytes_themes_produce_different_outputs():
-    """Sanity check: render the same artifact under both themes and
-    verify the bytes differ. This is a coarse but cheap regression
-    against accidentally short-circuiting the palette switch."""
+    """Sanity check: render the same artifact under two themes and
+    verify the PALETTE actually differs — a regression guard against
+    accidentally short-circuiting the theme switch.
+
+    Compares the extracted run-color set, NOT raw .docx bytes: a
+    .docx is a ZIP and python-docx stamps the current mtime into
+    every entry header, so two renders always have different bytes
+    regardless of content — a raw-byte `!=` would pass even if the
+    palette switch were broken. The color set is the real fingerprint."""
     artifact = _make_full_resume_artifact()
 
     artifact.theme = "classic_ats"
-    classic_bytes = export_docx_bytes(artifact)
+    classic_doc = _parse_docx(export_docx_bytes(artifact))
 
     artifact.theme = "professional_neutral"
-    neutral_bytes = export_docx_bytes(artifact)
+    neutral_doc = _parse_docx(export_docx_bytes(artifact))
 
-    assert classic_bytes != neutral_bytes
+    # classic_ats ships warm-brown ink/accent; professional_neutral is
+    # pure black/gray. Their run-color sets must differ.
+    assert _docx_run_color_hexes(classic_doc) != _docx_run_color_hexes(neutral_doc)
 
 
 def test_export_docx_bytes_unknown_theme_falls_back_to_classic_ats():
     """Unknown theme strings should resolve to classic_ats so the
     renderer never crashes on an unexpected artifact.theme value."""
     artifact = _make_full_resume_artifact()
     artifact.theme = "some_made_up_theme_we_have_not_built"
-
-    fallback_bytes = export_docx_bytes(artifact)
+    fallback_doc = _parse_docx(export_docx_bytes(artifact))
 
     artifact.theme = "classic_ats"
-    classic_bytes = export_docx_bytes(artifact)
-
-    # The unknown-theme render should be identical to classic_ats —
-    # same palette, same fonts, same content.
-    assert fallback_bytes == classic_bytes
+    classic_doc = _parse_docx(export_docx_bytes(artifact))
+
+    # The unknown-theme render must be EQUIVALENT to classic_ats —
+    # same content/structure, same palette, same fonts. We compare
+    # the extracted document, NOT raw .docx bytes: a .docx is a ZIP
+    # and python-docx stamps the current mtime into every entry
+    # header, so two renders a second apart differ byte-wise even
+    # when the content is identical (this test used to be flaky for
+    # exactly that reason). Compare what actually matters.
+    assert _docx_paragraph_pairs(fallback_doc) == _docx_paragraph_pairs(classic_doc)
+    assert _docx_run_color_hexes(fallback_doc) == _docx_run_color_hexes(classic_doc)
+    assert _docx_run_font_names(fallback_doc) == _docx_run_font_names(classic_doc)
 
 
 def test_export_docx_bytes_cover_letter_respects_theme():