ShortcutsSettingsView: keybinding conflict/cascade logic lives in the view with whole-store writeback

[onevcat]

Problem

The keybinding conflict and cascade-reset policy is implemented entirely inside ShortcutsSettingsView with @State pendingConflict / pendingResetConflict (ShortcutsSettingsView.swift:22-23), and edits are applied by writing a captured copy of the whole KeybindingUserOverrideStore through $store.keybindingUserOverrides.wrappedValue = overrides (:598-605, :633-638, :692). This routes through .binding(.set(...)) — so it is not a raw store mutation — but it deliberately sidesteps the store_state_mutation_in_views rule's intent, and none of the policy is reachable from a TestStore.

Failure scenario

A conflict plan is computed, an alert waits on the user, then the captured whole-store copy is written. Anything that changed overrides in between (e.g. AppFeature.swift:437 reassigns state.settings.keybindingUserOverrides on every settingsChanged) is discarded wholesale. The logic is also untestable.

Suggested fix

Move the conflict decision into SettingsFeature actions with AlertState, and have the reducer apply a per-command diff instead of a whole-store write.

Origin

TCA-conventions audit of the Settings area (2026-07-30), agent finding — structural; re-verify the writeback sites when picking this up.