Ligature characters (fi/fl/ffi) are dropped instead of expanded when extracting PDF text

## Summary
When converting a PDF that uses typographic ligatures (fi, fl, ffi, etc.), anydoc drops the ligature glyph entirely instead of expanding it to its constituent letters. This silently corrupts words in the output.

## Repro

npx -y @firecrawl/anydoc "EU AI-Act-overview-30-May-2024.pdf" -o out.md

Source PDF: https://artificialintelligenceact.eu/high-level-summary/ (also mirrored at futureoflife.org)

## Observed

| Expected | anydoc output |
|---------------------|---------------------|
| classifies | classi es |
| affected | a ected |
| influence | in uence |
| profiling | pro ling |
| identification | identi cation |
| traffic | traf c |

Reproduced consistently across the document (7+ occurrences), always at an fi/fl/ffi ligature boundary.

## Expected behavior
The ligature glyph should be expanded to its plain-text equivalent (e.g. "fi" glyph → "fi"), not dropped. For comparison, a separate OCR pipeline (pdftotext-based) on the same PDF preserves these correctly, either as the literal Unicode ligature codepoint (fi, fl) or as decomposed ASCII — either of which renders/reads correctly, unlike anydoc's current output which deletes the letters.

## Environment
- @firecrawl/anydoc version: 0.2.4
- Invocation: CLI, no --ocr flag (native PDF text extraction path — same result with --ocr hosted, since this PDF doesn't need OCR)
- OS: macOS

Reproduce the native PDF extraction path with the provided npx command and sample PDF, then trace the Rust code used by the CLI for PDF text extraction. Verify that fi, fl, and ffi ligatures are preserved or expanded rather than dropped, and confirm the corrected output across the listed examples.

Written by the indexing model from the issue text.