fix(settings): classify every find command as global so a grid binding cannot shadow one

[datlechin]

Follow-up to #2453. That PR was squash-merged carrying only its first commit, so the fix below never reached main.

Codex adversarial-review returned No-ship on #2453:

a supported Settings sequence can still create two Cmd+F menu claimants

The defect

Assign Cmd+F to Find Next, accepting the conflict against Find. Then assign Cmd+F to Toggle Filters. The second assignment is accepted, because findNext is classified .editor while toggleFilters is .dataGrid, so findConflict treats them as non-overlapping. Both are nil-targeted NSMenuItem key equivalents, so AppKit blanks one of the two and the user silently loses a command.

That classification was wrong on its own terms. MainSplitViewController.findNext and findPrevious both branch on hasActiveGridFind and route to the grid or the editor, exactly as performFind does. Context is what the conflict resolver uses to decide whether two bindings can collide, and a menu key equivalent is claimed window-wide, so a menu-backed command serving both surfaces has to declare the context that overlaps both.

.find was already .global for precisely this reason in #2453. Its two siblings were left behind.

The change

All three find commands are now .global. That is the whole fix.

Also fixed, and released rather than new

This closes a pre-existing hole with the same cause: binding a data grid action to Cmd+G raised no conflict against Find Next, because .dataGrid and .editor do not overlap, and AppKit then blanked one. MainMenuStructureTests.keyEquivalentsAreUnique could not catch it, because it only builds the default menu. There is now a regression test for it, and a CHANGELOG entry, since unlike the Cmd+F path this one is in a shipped build.

Verification

Built and tested against merged main:

Step	Result
verify.sh build	PASS
verify.sh test (14 menu + keyboard suites)	PASS, 95 executed, 95 passed

Tests added: every find command reports .global; Cmd+F parked on Find Next is still reported against a later filter bar claim; and a grid binding on Cmd+G conflicts with Find Next.

Note on scope

The uniqueness guarantee lives in conflict detection, not in the data model: KeyboardSettings.shortcut(for:) returns an explicit override unconditionally, so two overrides on one key would both resolve. Detection is what prevents that pair being created, and after this change it does. Closing the model-level gap as well would be defense in depth against anything writing KeyboardSettings without going through the recorder, and is deliberately left out of this PR.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.