fix(macOS): validate cached find ranges before Replace

[cursor]

Bug and impact

After the find/replace work, Replace / Replace & Find could use lastSearchHighlightRanges that no longer matched the live NSTextStorage. reapplySearchHighlights() skips out-of-bounds ranges when re-tinting after markdown restyle, but it does not clear those entries from the cache. The user can keep editing while the find UI stays open, so Replace could call replaceCharacters(in:with:) with an invalid NSRange (crash via NSRangeException) or replace the wrong slice of text.

Root cause

Stale cached highlight ranges coexisting with a mutated buffer; replace-current trusted the cache without re-validating against the current string.

Fix

• Before replacing, require the cached range to fit the storage and to span text that still matches the find query (case-insensitive), matching how matches are discovered.
• On failure, refresh highlights from the live document instead of mutating.
• Extract LinkAwareTextView.cachedHighlightRangeStillMatchesQuery for reuse and add SearchReplaceStaleHighlightTests.

Validation

• Added XCTest coverage for the validation helper (full Xcode test run not executed in this Linux agent environment).