"Glyph corruption (text renders as solid blocks) is also text-count dependent"

On a text-dense Razor panel with zero font-size or letter-spacing declarations, the last-rendered text element renders as solid filled blocks while identical sibling elements above it render as clean text. The content is irrelevant — even a plain string literal blocks. The corruption is positional: it hits the bottom/last-rendered text runs first, not specific classes or content.

This appears even when following the known rule of avoiding multiple font-size declarations. No errors are logged; compile_status reports Success = true.

The documented glyph-corruption rule — "beyond a low threshold of distinct font-size or letter-spacing declarations, all text on the panel becomes blocks" — has a second trigger: cumulative mono text-run count. Each text run on a ScreenPanel contributes to an internal glyph-atlas budget. When the total count of rendered text runs exceeds a threshold (observed around ~19+ mono runs on a single panel), the corruption manifests even with zero font-size declarations.

Unlike the font-size variant (which corrupts the entire panel), the text-count variant corrupts positionally — the last-rendered runs hit the threshold first, so bottom-of-panel text blocks while top-of-panel text stays clean. Expanding a collapsed section (which swaps the corrupt span for different markup) can render fine because the swap changes which run hits the threshold.

Treat mono text-run count as a budget on text-dense panels:

1. Trim the least-important text. Collapsed-section summaries are a good sacrifice — the values reappear on expand. Removing even one text run near the threshold can bring the whole panel back under.
2. Combine text runs where possible. Two adjacent <span> elements count as two runs; a single <span> with the combined content counts as one.
3. Verify on a play-mode camera_screenshot, never headless — the corruption is render-path dependent and may not reproduce in all capture modes.

Do not assume you are safe because you added no font-size declarations. Both triggers (font-size declaration count and text-run count) feed the same underlying glyph-atlas budget.

The engine's glyph atlas has a fixed capacity. Each distinct text run contributes glyphs to the atlas. The font-size variant was documented first because varied sizes multiply the glyph entries, but a high count of same-size runs can exhaust the same budget. Reducing the run count keeps the panel under the atlas threshold, and the positional corruption disappears because the remaining runs all fit.