Fix search-active scroll lock (issue #19)

[aydiler]

Fixes #19.

Summary

With the find bar open, wheel-scrolling away from the active match snapped the view back every frame, leaving the user locked near the result. Esc to dismiss the bar restored scrolling — the workaround documented on the issue.

Root cause

The post-render corrective scroll in render_tab_content was designed as stage 2 of a two-stage scroll (line-ratio estimate → snap to renderer-recorded active_search_y). After commit 21d43c5 disabled show_scrollable virtualization, the renderer started walking the full event stream every paint, and record_active_search_y_viewport fires unconditionally per Active highlight segment (egui's clip rect culls painting but not widget layout). So active_search_y became perpetually fresh, and the corrective block — which had no guard for "user just scrolled" — snapped back every frame the match was off-screen.

Fix

One-shot correct_active_search_pending: bool on Tab. Set by scroll_to_active_match (called from jump_match / maybe_rebuild_search). The corrective block is now gated on the flag and clears it after running once. Two-stage scroll still converges in 1–2 frames; subsequent wheel input is no longer overridden.

Full root-cause / repro write-up: docs/devlog/031-search-scroll-lock.md. LESSONS entry added.

Test plan

• Xvfb + xdotool 500 wheel-down events on a 3-page test doc — net scroll went from 16 px (213 snap-back frames) to ~2800 px (0 snap-backs after initial paint).
• User-confirmed on real display.
• CI green.