fix: isolate unrenderable glyph failures

[oz-for-oss]

Closes #9372

Summary

• Cache deterministic glyph rasterization failures as missing glyphs so one unsupported fallback glyph cannot blank the entire terminal glyph layer.
• Continue rendering remaining glyphs in WGPU and Metal renderers when a per-glyph cache error occurs.
• Return a controlled swash rasterizer error instead of panicking when a subpixel raster image is unavailable.
• Add glyph cache unit tests covering raster-bounds failures, rasterization failures, and rendering other glyphs after a cached missing glyph.

Validation

• cargo test --manifest-path /workspace/warp/Cargo.toml -p warpui rendering::glyph_cache --lib
• cargo check --manifest-path /workspace/warp/Cargo.toml -p warpui --lib

Notes

• cargo fmt --manifest-path /workspace/warp/Cargo.toml --all could not run because rustfmt is not installed for the stable toolchain in this sandbox.

[ATERCATES]

Hitting this same bug on Linux (WGPU) — happy to share an independent repro and validation in case it helps move this out of draft.

Repro (reliable):

• Linux, latest stable Warp
• Use any oh-my-zsh theme that prints ✗ (U+2717, BALLOT X) in the prompt to mark a dirty git tree (e.g. jnrowe)
• cd into a repo with uncommitted changes

The whole prompt + surrounding region blacks out. Scrolling forces a redraw and the previous content reappears, which is what tipped us off that the buffer was intact and only the render layer was being dropped.

Logs match exactly what this PR addresses:

[WARN] [warpui::rendering::wgpu::renderer::glyph] Unable to get glyph out of glyph cache: Failed to get raster image, Glyph { glyph_key: GlyphKey { glyph_id: 1059, font_id: FontId(120), font_size: OrderedFloat(13.0) }, position: Vector2F(<811, 64>), fade: None, color: #fefdc2 }

The same glyph key (glyph_id: 1059, font_id: 120, 13pt) was hitting the warning at ~60 Hz before the cache populated with the failure, which is exactly the "deterministic raster failure spamming the renderer every frame and blanking the layer" behavior described in the summary.

Validation:

I cherry-picked this PR's commit onto current master and built locally. The blackout is gone — failing glyphs are now skipped individually, the rest of the layer renders normally, and the warning is emitted exactly once per problematic glyph instead of per frame. The unit tests covering raster-bounds errors, rasterization errors, and mixed renderable/failed glyphs all pass.

The underlying "why does U+2717 fail to rasterize at all" question (font fallback gap) is separate from this fix, and I agree with the scope here — a single bad glyph shouldn't be able to take down an entire render layer regardless of cause.

Any chance this could be moved out of draft? It's a daily annoyance for Linux users with themes that show status glyphs in the prompt.

[FurryR]

Seems to be replaced by #13144 which probably solved your problem?