Keeping Find open does not rescan the document on every frame

[jsmestad]

Type: Bug

Severity: High. Ordinary interaction scales with document size while Find is open, even when neither text nor query has changed.

What

With a nonempty GUI search active, every semantic UI build fetches the whole document, splits its lines, allocates every match, and walks the result for the current position. Cursor-only and unrelated chrome frames repeat this work before encoder fingerprint suppression.

Why

Ordinary interaction scales with document size while Find is open, even when neither text nor query has changed.

Grounding Evidence

Verified against main@ac343a9c2bc6 on 2026-09-08.

• Every UI build constructs search state (lib/minga_editor/render_model/ui/builder.ex:58).
• Search statistics fetch and scan the complete buffer (lib/minga_editor/render_model/ui/search_state_builder.ex:46).
• Output deduplication happens after search computation (lib/minga/frontend/adapter/gui/search_state_encoder.ex:20).
• Undo restores a prior document version (lib/minga/buffer/process.ex:1683); freshness must also check the monotonic change sequence.
• The current wire narrows count and ordinal to u16 (lib/minga/frontend/adapter/gui/search_state_encoder.ex:46).
• The encoder intentionally rejects an out-of-range count (test/minga/frontend/adapter/gui/search_state_encoder_test.exs:71).
• Native search state also uses UInt16 (macos/Sources/Views/EditorChrome/SearchState.swift:32).
• The toolbar presents a zero count as No results (macos/Sources/Views/EditorChrome/SearchToolbar.swift:42), which must not represent pending or failed asynchronous work.

Evidence level: Source-established work proportional to the whole document on each active-search render, with source-verified version and wire-capacity constraints for the replacement path. No end-to-end latency benchmark was run for this path.

Acceptance Criteria

1. After the first search, cursor-only and unrelated frames perform no full-document fetch or match scan while text/query/options remain unchanged. Implemented in PR #3384.
2. Counts, next/previous navigation, and current-match position agree with a fresh search after text edits, undo/redo, query/options changes, and buffer switches, including more than 65,535 matches without overflow or truncation. Implemented in PR #3384.
3. Initial and replacement searches run outside latency-sensitive Editor/render callbacks. Delayed results from another query or buffer revision never publish, including undo/redo that restores an earlier version number. The toolbar distinguishes loading, rebuilding, and failure from a completed search with zero matches. Implemented in PR #3384.
4. Ordinary line-local edits update affected results and downstream positions without rescanning unchanged document text for either literal or regex queries. Bulk edits or missing change history trigger one current asynchronous rebuild, never approximate results. Implemented in PR #3384.
5. Large-document Release evidence reports matching work separately from render/encode work and preserves the existing search behavior. Implemented in PR #3384.

Delivery

Implemented by PR #3384.