Avoid duplicate profile-grid refresh after local commits

[KeyffMS]

Priority

P2

Context

Found during a static KISS/DRY/SPOA/SPOT/Clean Code audit of main at commit 2197699d853a1e1446adcbd7ccdd98fcc02692bd.

Problem

VisualProfileManagerForm subscribes to SettingsCoordinator.Changed, and its handler rebuilds the profile grid. SettingsCoordinator.Commit raises that event synchronously before returning.

After a successful local commit, the manager then calls RefreshProfiles(result.Value) again. Each create, duplicate, rename, edit, or delete operation therefore performs two full grid rebuilds.

Impact

• unnecessary UI work and possible flicker;
• transient selection changes during the first refresh;
• more complicated reasoning about which refresh owns the final selection;
• behavior differs from ConfigurationForm, which already suppresses its own synchronous refresh during grid commits.

Proposed direction

Add a local-commit suppression flag or equivalent scoped mechanism:

1. suppress the form's Changed handler while its own commit is executing;
2. refresh exactly once after the result is known;
3. preserve/select the intended profile ID.

External settings changes must continue to refresh the manager normally.

Acceptance criteria

• a successful local manager commit rebuilds the grid once;
• external SettingsCoordinator.Changed events still rebuild the grid;
• selected profile ID is preserved or intentionally changed after each operation;
• failure paths refresh once from committed settings;
• a regression test verifies local and external refresh behavior.

[KeyffMS]

Implemented and validated in release 0.5.0.23 (46563f2937492e0a0c9267d7b4b53acda3a66fcc).

Validation run: 29985315044.

Local manager commits now suppress their synchronous SettingsCoordinator.Changed refresh and rebuild the grid exactly once after the commit result is known. External settings changes still refresh once. Dedicated STA regression tests cover both paths, and the complete test suite plus self-contained win-x64 publish passed.