feat(flterm): render Kitty Unicode placements

[elias8]

Resolves #125

Expose Kitty Unicode placement iteration through libghostty bindings and render resolved occurrences in flterm while suppressing protocol placeholder glyphs and preserving image generation matching.

Blocked by ghostty-org/ghostty#13523

[adonm]

Reproduced the yazi path end to end against 0.0.5/0.0.12 and can confirm the diagnosis: yazi sends q=2,a=T,C=1,U=1,… plus U+10EEEE placeholder cells (id in fg color) and never sends a=p. KittyGraphics.placements() yields the isVirtual entry and image() returns decoded RGBA — but viewportVisible is always false for virtual placements, so KittyPlacementCache.sync skips them and previews stay visible as tofu.

I verified plain a=T + a=p painting works pixel-level (DPR scaling, alt screen, chunked transmits all paint), so this is U=1-specific.

Workaround I landed in a fork ( opportunistic, no new C API needed): resolve placeholder runs from grid content — maximal same-id rectangles via GridRef codepoint + truecolor fg, screen-space rects converted with the viewport offset — into paint snapshots with the virtual placement's z-index, and return null for U+10EEEE in CellContentResolver.resolveCell (kitty proper hides placeholders too). Branch: adonm/libghostty zuko/kitty-unicode-placeholders (based on the 0.0.5 source commit 492d380), with fork-side cache tests (resolve/erase/unknown-id) and a pixel-level widget test proving yazi-style U=1 paints. Happy to PR it if useful before #13523 lands.

Two harnesses notes that cost me time: (1) image decode completes via a native callback, so widget-test captures need real-loop yields (runAsync) plus a post-decode pump — fake-async pumps alone capture pre-decode frames; (2) placeholder cells are non-BMP, so test bytes must be utf8.encoded — Dart string .codeUnits are UTF-16 and arrive as U+FFFD, which the resolver correctly ignores.