Organizer on Windows: selecting a calculation erases tree rows, rebuilds the summary and menus in view #254

9.0.0-alpha.10, Windows 10. Selecting a calculation in the Organizer tree redraws large parts of the window visibly. These findings come from a 60 fps screen recording of clicking through six calculations in turn.

Observed, frame by frame

1. Tree rows: the previously selected and the newly selected rows are both erased (e.g. selecting Calculation-1 after Calculation blanks both). They stay blank for about 0.3 s (≈18–19 frames), with the busy cursor shown, before they are drawn again. Selecting row k after row k−1 therefore blanks k and k−1, and row 1 pairs with row 6 when the order wraps around.
2. Summary pane: the right-hand pane is emptied and then rebuilt piece by piece in view.
   • blank;
   • only "Calculation:" and the Editor button;
   • half the property rows, with some tool buttons missing;
   • complete.
3. Menu bar: during the update it shows only "File Edit"; the other menus are removed and added back.
4. Empty square: a grey square appears for a moment where a tool button is created, before the button has its image and position.

Likely cause: the selection handler does all of the following synchronously, without suppressing redraws:

• rebuilds the summary panel's controls (destroy + create);
• rebuilds the menus;
• loads the calculation's data (~0.3 s).

On MSW every intermediate state is painted, and the erased tree rows cannot be repainted until the handler returns. 1fd19eb (alpha.8, "repaint the tree after a selection change") only mitigated item 1. The CalcMgr notice batching in 9a5ebca covers Save/Launch, not selection.

Proposed fix

• Hold redrawing of the tree, the summary pane and the menu bar for the whole update (wxWindowUpdateLocker / Freeze–Thaw) and draw once.
• Update the summary's existing controls instead of destroying and recreating them.
• Rebuild the menus only when the set of tools changes.
• Paint the new selection first and do the slow load afterwards (CallAfter), so the tree never shows erased rows.
• Measure with tests/windows/framelog.ps1, plus a test hook that counts summary rebuilds and menu rebuilds per selection.

Linux (GTK) is less visibly affected, but the same work runs there; check that it does not regress.