Route Find to AvaloniaEdit's search panel on editor windows

[simtel12]

Summary

• Cmd+F (or the dock menu's Find…) on an AvaloniaEdit-backed game window now opens AvaloniaEdit's own search panel instead of the plain in-window Find bar, giving live match highlighting and regex/case/whole-word toggles. FindInWindowModel gains an OpenOverride hook so a renderer can claim Find while it's attached; GameTextEditor wires it to the SearchPanel and releases the claim on detach.
• Ctrl+F still opens the in-window bar everywhere, and non-editor windows are unaffected.

Test plan

• Cmd+F on an editor-backed game window opens AvaloniaEdit's search panel with match highlighting
• Ctrl+F still opens the in-window Find bar on all windows
• Dock menu's Find… routes to the same UI as the keyboard shortcut
• A user macro bound to Cmd+F or Ctrl+F takes precedence over the built-in shortcut

[simtel12]

Switching back to draft as I want to test it on both Mac and Windows before review.

[monil2233]

Status: reviewed while in draft — no blockers, but one behaviour note to settle before it comes out of draft.

Re-checked against current main (deba7ad): merges clean, CI build green, and the split of the chip-strip fix into #259 is clean — no leftovers here.

The design reads well. Putting OpenOverride on the model and the routing decision in the control is the right split: only the renderer that actually drew the window knows which surface is showing it. Returning false before the template applies, so the caller falls back to the bar instead of a dead keystroke, is a nice touch, and releasing the claim on detach with the identity check (if (_find.OpenOverride == OpenSearchPanel)) is correct — delegate equality compares target and method, so a second renderer's claim is not clobbered by the first one detaching.

The one thing worth settling: on Windows and Linux this changes Ctrl+F, not just Cmd+F.

PlatformCommandModifiers resolves to Control off macOS, so the new platform block matches Ctrl+F first, calls Open(), and returns. The #120 block below it is then unreachable on those platforms — it only ever serves macOS now. Net effect on Windows/Linux with useeditorgamewindow on: Ctrl+F opens the AvaloniaEdit panel, and the in-window Find bar has no remaining way to be reached on that window.

The code comment says this plainly, so it looks intentional, but the PR summary says "Ctrl+F still opens the in-window bar everywhere", which only holds on macOS. Two ways to reconcile:

1. Keep the behaviour (the panel is the better UI, so everyone gets it) and fix the summary — but then say so in the release notes, because it is a visible change for existing Windows users of the editor renderer.
2. Keep the bar reachable off macOS too, by gating the new block to PlatformCommandModifiers != KeyModifiers.Control.

Either is defensible; option 1 with a note is probably the honest one. If it lands as-is, the two macro guards should collapse into one — IsMacroBound(Key.F, …) and the inline Macros?.Get("ctrl+f") check are the same test spelled twice, and off macOS only the first ever runs.

Smaller notes:

• Test plan item "a user macro bound to Cmd+F takes precedence" cannot fail as written: MacroKeyConverter only emits ctrl/alt/shift names, so a Cmd-modified keystroke is never macro-bindable in the first place. The Ctrl+F half of that item is the one that actually exercises the guard.
• FindInWindowModel.Open() is pure model code and currently has no coverage anywhere — worth two small tests (override returns true → IsOpen stays false; no override → IsOpen becomes true). Cheap, and it pins the fallback contract that the whole design rests on.

No rush from this side — take the Mac and Windows passes you wanted.