Fix #811: unnamed glyphs of an installed font stay in their type

[bflatastic]

Fixes #811.

In a PDF, or the PDF part of an .ai file, a subset-font glyph that nothing names (no ToUnicode entry, no CID table, no character map in the embedded font program) was drawn as outlines. One text object then came in split: "RADA" became the type "ADA" plus the R's outline.

Now, when the font is installed, such a glyph is looked up there by its outline (identify_glyph in crates/pdf/src/import.rs):

• The candidates are the characters single-byte fonts encode: ASCII, Latin-1, Latin Extended-A, general punctuation, the euro and trade mark signs, and the fi/fl ligatures.
• The first candidate whose installed glyph draws the same outline, point for point within 2/1000 em once scaled into the PDF's glyph space, names the glyph. A subset carries the font's own outlines, so an installed copy of the same font finds every glyph.
• Other versions of the font, empty glyphs (every space draws one) and glyphs that are no character keep their outlines, with the warning as before.
• Results are cached per (font, glyph), so each unnamed glyph is looked up once per import.

.ai files with editing data don't need this: their type comes from the text document (#637). It covers plain PDFs and the PDF part.

Tested:

• cargo xtask ci (all 7 steps); all 218 vectorcraft-pdf tests.
• The Glyphs whose ToUnicode maps to U+FFFD render as "�" (digits lost in Illustrator .ai files) #708 test whose digits map to U+FFFD now reopens "Tel 02-12345" as one type object with no outlines left and no warning (it used to keep the digits as outlines).
• New glyphs_are_named_only_by_an_exact_outline: R, a, 7, & and é are found by their outlines; the same outline moved by a tenth of an em, and an empty outline, are not.

🤖 Generated with Claude Code