fix(manager): keep settings grid usable after delete

[Ibochkarev]

What changed and why

After you delete a context setting from the grid, the next inline edit or delete often returned “Setting not found”. MODx.grid.Grid.remove() wrote action and the deleted key straight onto shared config.saveParams. Later autosave (saveRecord → UpdateFromGrid) merged those polluted params into another row and sent the wrong key.

remove() now clones saveParams before mutating. Settings grids also return false from afterRemoveRow after refreshFilterOptions() (which already reloads the store), so removeActiveRow does not race with a second store.remove(selection).

How to test

1. Manager → Contexts → edit web → Context Settings.
2. Create three settings (e.g. test_a, test_b, test_c) with any values.
3. Delete test_a from the grid menu.
4. Double-click test_b value, change it, blur/save — should succeed (no “Setting not found”).
5. Delete test_c — should succeed without a page reload.

node --check manager/assets/modext/widgets/core/modx.grid.js
node --check manager/assets/modext/widgets/core/modx.grid.settings.js
# exit 0

Browser smoke on revolution.test: after remove, config.saveParams stays {context_key:"web"}; UpdateFromGrid for the next row returns success.

Related issue(s)/PR(s)

Resolves #14280

Compatibility notes

Manager ExtJS grids that use config.saveParams with remove() (context / system / user / usergroup settings). No PHP or connector API change.

Breaking change assessment

No public API change. Behavior fix only: remove no longer mutates the shared saveParams object.

Test coverage

No ExtJS unit harness in-repo. Verified with node --check and a manager smoke that deletes one context setting then UpdateFromGrid on another.

Contributors

@GulomovCreative reported the original bug.

AI tool use

Cursor (Composer) traced the saveParams leak, applied the clone + afterRemoveRow veto, and drafted this PR body. Browser checks on revolution.test confirmed the polluted params before the fix and clean autosave after.

[smg6511]

My testing verifies that the cloning of the saveParams fixes the issue. The other changes weren't really needed from my observations, although I did suggest an update to the afterRemoveRow method, as the original implementation didn't make sense.

[smg6511]

Looks good!