Code fences use four tones, not eight (kptd7)

A rendered fence carried eight distinct colours. One was the raw ANSI name magenta, which bypassed the palette entirely and so rendered the same in every variant. One was the brand accent doing syntax-highlight duty, which the accent budget — two claims per screen — does not stretch to.

Keywords and types now share one code tone, strings and numbers share another, comments take the faint neutral, and functions, attributes and plain text inherit the body colour. Four tones total: the bulk of most code is the bulk, and colouring the bulk is what made a fence read as decoration. The five per-kind colour constants were deleted rather than moved into the palette — the problem was the count, not the location.

Comments no longer stack dimColor on top of the faint tone. That tone is faint by design, and dimming it again made comments invisible on some terminals.

Markdown's H1 also moved off the warning tone, which is the same hex as the cancelled and blocked run states — a top-level heading and a dead run were the same colour. The heading ladder is now accent, body text, strong-muted, muted: monotonic in prominence, one accent claim instead of two.

Known Limitations and Deferred Work. H4 deliberately shares the muted neutral with the queued state and that is not a collision to fix — both a fourth-level heading and a not-yet-started run are legitimately the quietest thing on screen, and forbidding the shared neutral would remove the tone the whole ladder is built on. npm run selftest:tui-code-fence-palette therefore asserts H1 through H3 against the state palette, not H4.