Symbol-font bullets (U+F0B7) render as a wrong glyph instead of • #29

Version: wordcraft 0.3.0, Linux x86_64 release tarball (Arch-based distro, Wayland)

What happens

In a bulleted list from a .docx that uses Word's standard bullet, the bullet renders as a wrong glyph that looks like a small logo or arrow, not a round dot. Second-level bullets ("o" in Courier New) render correctly.

Cause (as far as I can tell)

The bullet level is defined the way Word writes it by default:

<w:numFmt w:val="bullet"/>
<w:lvlText w:val="&#xF0B7;"/>
<w:rPr><w:rFonts w:ascii="Symbol" w:hAnsi="Symbol" .../></w:rPr>

U+F0B7 is a Private Use Area code point that only means "bullet" in the Symbol font. When Symbol isn't installed (common on Linux), the fallback font draws whatever it has at U+F0B7. Word and LibreOffice map Symbol-font PUA characters (U+F020–U+F0FF) back to their standard Unicode equivalents (U+F0B7 → U+2022 •) when Symbol isn't available.

Steps to reproduce

printf -- '- one\n- two\n  - nested\n' > list.md
pandoc list.md -o list.docx        # pandoc 3.10.2; its reference docx uses Word's default Symbol bullet
wordcraft-cli render list.docx list.png

The same glyph shows up in the app and in wordcraft-cli convert list.docx out.pdf.

Expected

A round bullet (•), as in Word and LibreOffice.

Suggested fix

Map Symbol (and maybe Wingdings) PUA characters to their Unicode equivalents when that font isn't available, at least U+F0B7 → U+2022 and U+F0A7 → U+25AA (Wingdings §-square, also common in Word lists).