Diffs are filled, not coloured (k7pc0)

Added and removed lines in the diff viewer render as a line BACKGROUND with readable text on top, the way delta and git render a diff — not as coloured glyphs.

The previous rendering used TONE.diffAdd / TONE.diffRemove as the whole-line FOREGROUND. Those two tokens are Claude Code's diffAddedWord / diffRemovedWord, which are intra-line WORD highlights; only that variant had been ported, so a word-highlight colour was doing whole-line duty. Measured against the dark ground, remove landed at 2.92:1 and add at 4.29:1 — the densest, most-read text in the product, below the 4.5:1 floor.

The fills are Claude's own diffAdded / diffRemoved line backgrounds. Every variant now measures between 7.97:1 (claude-dark add) and 14.76:1 (light remove); npm run selftest:tui-diff-contrast asserts all of them by reading the palette, so a later palette edit that darkens a fill turns red. The *Word tokens keep their real job, intra-line emphasis.

Two things that look like bugs and are not: on a terminal with a transparent background the fills render as solid bands, which is correct; and in the dark variant "added" is BLUE rather than green, because the daltonized palette must stay distinguishable to a deuteranope — the smoke asserts that too, so a future edit cannot quietly "restore" green.

Known Limitations and Deferred Work. The ansi variant cannot be measured — its values are terminal-defined names, not hex — so only the weaker guarantee is asserted there: add and remove remain distinct fills. Word-level intra-line highlighting is not implemented; the *Word tokens exist and are correct, but nothing computes which words changed yet.