Add pymupdf4llm_html_tables pipeline (thread table_output=html through the provider)

[veget-able]

Note

This PR targets the upcoming improved PyMuPDF / PyMuPDF4LLM builds, not stock 1.28.0.
With the current stock wheels the table_output keyword is accepted and ignored, so this
pipeline produces the same output as pymupdf4llm_markdown today. It is sent ahead of the
improvement release so the benchmark wiring is already in place when the new builds land -
the 72.11 GTRM below was measured against those improved builds.

Summary

Adds a one-keyword passthrough so the pymupdf4llm PARSE provider can request the
native HTML table engine, plus a pymupdf4llm_html_tables pipeline that turns it
on. This is what makes the pymupdf/pymupdf4llm table work measurable on ParseBench.

Two small commits, 3 files, +43 lines:

• _markdown_options() reads an optional table_output config key (validated to
  {"markdown","html"}) and forwards it to pymupdf4llm.to_markdown.
• New pipeline pymupdf4llm_html_tables = the existing pymupdf4llm provider with
  config={"table_output": "html"} (same OCR/layout defaults as pymupdf4llm_markdown,
  only the table rendering flips to HTML).

Why

The improved pymupdf4llm build renders reconstructed HTML tables only when
to_markdown(..., table_output="html") is passed — it is opt-in. Without this
passthrough the layout path emits the same markdown pipe-tables as the stock build,
so the benchmark cannot see the table work at all:

Pipeline	Table rendering	GTRM (table group)
engine not wired (markdown tables)	pipe-tables	56.73
table_output="html" wired (this PR)	native <table>	72.11

Tables group: GTRM = GriTS + TableRecordMatch, 503 pages / 284 docs. The 72.11 was
verified end-to-end through this exact branch + pipeline (pymupdf4llm_html_tables,
--max_concurrent 1, 503/503 success) against the improved pymupdf/pymupdf4llm builds.

Compatibility

• Existing pipelines are byte-for-byte unchanged — the kwarg is only sent when a
  pipeline explicitly sets table_output in its config; none of the current
  pymupdf4llm_markdown* pipelines do. Verified: _markdown_options for the baseline
  emits no table_output key.
• No new layout wiring needed. pymupdf4llm auto-activates the layout engine on
  import (_use_layout=True), which this provider already relies on for page_boxes,
  so table_output="html" lands on the preferred layout+HTML path with no extra import.
• Stock pymupdf4llm 1.28.0 ignores the extra keyword (verified empirically: same
  markdown pipe-table output, no error), so the pipeline degrades gracefully when the
  HTML table engine is not present.

How to run

# Table dimension only, single-threaded (PyMuPDF's layout engine carries global
# state — run at concurrency 1 for reproducible table scores):
uv run parse-bench run pymupdf4llm_html_tables --group table --max_concurrent 1

Not included (deliberately minimal)

• No use_tgif env toggle — it is a no-op in current stacks and this provider does
  not read it.
• No standalone LAYOUT_DETECTION (to_json) provider — that's a separate benchmark
  task from the PARSE table quality this PR targets.
• No leaderboard.csv row yet — can add one after a scored run in the canonical
  environment.

Companion analysis of the underlying table engine (PyMuPDF table.py + pymupdf4llm,
GTRM measurements, TableFinder/TableHunter comparison) is available on request.