Renderer: TrueType subset of a CID-keyed CFF font has no outlines on macOS (CoreText) #702

Found on the builtin-engines branch (Project 4, built-in engines), in the PDF backend from #683.

FontSubsetter turns a CID-keyed CFF font (tests/Filee.Engines.Tests/Fonts/FileeTest-CID.otf, a Noto Sans KR OTF subset) into a TrueType subset. On Windows and Linux, Skia reads the subset and every glyph has its outline. On macOS (both CI runners, macos-15 arm64 and macos-15-intel), SKFont.GetGlyphPath returns null for the subset's glyphs. The name-keyed CFF sample works on macOS.

#698 made FontSubsetterTests.Cff_font_becomes_a_truetype_subset_with_the_same_shapes say which side is missing: "glyph 1: the subset has no outline for it". So it is the converted subset, not only the CFF original, that CoreText can't outline.

Why it matters: on macOS, the renderer would write Korean / CJK text in fonts like Pretendard or Noto Sans CJK (OTF) with glyphs CoreText can't draw. That affects the PNG pages, and the PDF if Skia relies on the typeface's outlines there.

To look at:

• whether CoreText rejects the whole subset (e.g. a table it validates more strictly than FreeType: head, maxp, loca/glyf alignment, OS/2, post, name) or only these glyphs;
• what differs between the CID-keyed and the name-keyed path in CffToTrueType / FontSubsetter (FDSelect, per-FD private dicts, the units-per-em fix from feat(engines): PDF backend spike: font subsetter and Skia page writer #683);
• running the subset through ftxvalidator / fontTools on a Mac.

Until then, the test skips this case on macOS with a reference to this issue.