NSTextStorage restyle over the whole buffer moves the clip view with non-contiguous layout; a diff-only apply avoids it

With NSLayoutManager.allowsNonContiguousLayout = true, a setAttributes pass over the full range of NSTextStorage (even inside beginEditing/endEditing, and even with identical text) can move the NSClipView origin by thousands of points mid-file during processing; it often lands back on the same top line, which looks like a jump-and-return flicker. Applying only the runs whose attribute dictionary differs (NSDictionary isEqual against storage.attributes(at:longestEffectiveRange:in:)) gave zero clip movement in an off-screen test, even when the diff covered the whole tail after the caret (opening a block comment). The end state matches a full restyle because setAttributes replaces the whole dictionary. Trade-offs: the per-run compare was about 1.5x slower than blind setAttributes for 13k runs, and a theme change still touches every run, so it still jumps; wrap that path in a save/restore of the top-line anchor. To restore the viewport after a word-wrap reflow, anchor on the first character of the top line fragment plus an offset clamped to the new fragment height, not the numeric clip origin; the numeric origin drifted about 30 lines per toggle.