[Bug] Windows Settings window becomes unresponsive on certain changes

[xiaolai]

Split from #787 (comment #3 in the original report).

Observed

On Windows, some Settings window changes — notably language switches and keyboard-shortcut edits — briefly freeze the window, and occasionally leave it non-responsive ("on-off" per the original reporter).

Suspected cause

Those changes trigger a synchronous full menu rebuild on the main thread. The rebuild walks the entire menu tree and reinstalls every accelerator, which on Windows takes long enough to block the UI thread noticeably. The menu subsystem has no differential-update path today — every accelerator change is a full rebuild.

Proposed direction (not yet implemented)

1. Move the menu rebuild off the UI thread (async task) so the Settings window stays responsive.
2. Replace full rebuild with a differential accelerator update: compute the diff between old and new accelerator sets and only reinstall what changed.
3. Debounce rapid settings changes so a batch of shortcut edits coalesces into one rebuild.

Option 2 is the correct long-term fix but the bigger change. Option 1 would be a quick partial mitigation.

Reporter

Originally reported by @iamHTV on Windows, VMark 0.6.42 (#787).

Repro checklist (for future verification)

• Windows, VMark running
• Open Settings → change language → observe freeze
• Open Settings → edit a keyboard shortcut → observe freeze
• Rapid-edit multiple shortcuts in a row → does window ever become fully non-responsive?