Live waveform/log views: don't reset a derived per-row cache on every append (O(n^2) over a long run)

A common pattern in live-updating viewers (waveform rows, log panes, chart series): when new samples are appended, the code invalidates a derived cache (formatted value strings, layout, text widths) for the whole row and rebuilds it on the next render. Every poll then costs O(total history), so a long live session is quadratic and gets slower the longer it runs.

Measured in one viewer: 400 appends caused 82,209 formatter calls. After the fix, 804.

Fix: treat the cache as append-aware. - Track the index of the first change that an update actually rewrote. Appends rewrite nothing before the old tail; a late correction or backfill may rewrite from some earlier index. - Truncate the cache to that index and extend it over the new tail only. - Keep a full rebuild only for real invalidations (format/radix change, width change).

Test it with a counter, not a timer: count formatter calls for N appends and assert O(N) (e.g. calls <= c*N). That test is deterministic and fails clearly on the quadratic version, while wall-clock tests flake.