fix(xlsx): render float values faithfully instead of 6-digit scientific notation

[Manohar Paturi (ManoharPaturi)]

Fixes #2532.

Passes float_format to both to_html call sites so a float renders as the shortest string that round-trips its stored value instead of pandas' 6-significant-digit scientific notation. Integral columns keep rendering through the existing paths (the integer formatting from #2485-style handling is untouched; 42.0 in a genuinely-float column renders as 42.0).

Regression test asserts 123456789.123 survives and 1.234568e+08 does not appear (fails on main). Existing xlsx/xls suites green (27 passed).

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[XU (kokokoXUY)]

This PR for #2532 currently contains the fenced-code whitespace change from #2529 and the DOCX heading change from #2531 as well as the XLSX float change. Both earlier PRs are still open against main. In particular, this branch still has the original fenced-code normalizer from commit b069ae1, while #2529 was updated to 7e6ed5c after review to fix the fence-boundary case. I compared the current _markitdown.py at all three PR heads: #2531 and #2533 have the same older file, and #2529 has the revised one.

Could you rebase or cherry-pick so this PR's diff against main contains only the XLSX float change and its test? That would keep the already-reviewed fence correction and the separate DOCX work from being mixed into this merge.

[Manohar Paturi (ManoharPaturi)]

XU (@kokokoXUY) good catch, the branch had grown by stacking. rebuilt it from current main so the diff is exactly the xlsx float change and its test (383fe6d, single commit). the docx PR (#2531) had the same stacking and is rebuilt the same way (4121d96).

[Çağdaş Yürekli (cagdasyurekli)]

I verified 383fe6d with pandas 2.3.3 and 3.0.5. The reported 123456789.123 example, 0.1, 1e-10, and a mixed text/number XLSX column retain their values. I also checked a generated XLS workbook with the same numeric values; that path passes too. The PR's existing regression test passes.

One small test improvement: the patch changes both XLSX and XLS conversion, but the committed regression only exercises XLSX. Could you add an XLS case and assert the 1e-10 value already included in the XLSX fixture? That would protect both call sites and the small-number behavior. I did not find a blocking conversion defect in the cases above.

[Çağdaş Yürekli (cagdasyurekli)]

Added the suggested test coverage on top of 383fe6d: 8936a6f (patch). Feel free to cherry-pick it.

This adds the missing 1e-10 assertion and a synthetic XLS fixture exercising 123456789.123, 0.1, and 1e-10 through convert_stream. Fixture provenance is included; xlwt is not a runtime/test dependency. No production code changes.

Both tests pass with pandas 2.3.3 and 3.0.5. Full core suite on Python 3.12: 968 passed, 43 skipped; Black 23.7.0 and diff whitespace checks pass.