fix(buzz-media): recover OOXML mime from zip central directory (#2964)

[Explaimaus-Hash]

Fixes #2964

Problem

infer's positional OOXML matcher (is_xlsx/is_docx/is_pptx) walks
forward from the front of the zip, hopping local file headers within a
~6KB window to find the 3rd entry — the one whose subdirectory name
(xl/, word/, ppt/) identifies the document type. Real spreadsheets
and documents commonly push that header past 6KB once early entries
(themes, styles, docProps/core.xml) are populated, so the matcher gives
up and infer reports a bare application/zip. Small test files stay
under the window and pass; real-world files silently don't.

Fix

Added disambiguate_ooxml_zip(): when infer reports application/zip,
re-check the file's central directory instead of the local headers.
Every entry name is listed there in a fixed-size record regardless of how
large its data is, and the directory's location is computed from the
End-of-Central-Directory record at the tail of the file — no bounded
forward walk required. The generic file-upload path already buffers the
whole request body before validating, so the central directory is already
in memory here; no streaming constraint applies.

Considered raising infer's sniff window instead, but the central-directory
check is deterministic regardless of entry size/order, and it only kicks in
for files infer already resolved to application/zip — nothing else
changes.

Testing

• cargo test -p buzz-media — 107 passed, 0 failed
• New tests reproduce the exact bug (large xlsx with an 8KB-padded
  docProps/core.xml) and confirm plain zips / non-OOXML archives are
  left untouched:
  • test_disambiguate_ooxml_zip_recovers_large_xlsx
  • test_validate_file_large_xlsx_detected_correctly_end_to_end
  • test_disambiguate_ooxml_zip_ignores_plain_zip
  • test_disambiguate_ooxml_zip_detects_docx_and_pptx