Refactor Phase 3 (optional): table-drive the menu + shortcut builders

Follow-up to #3351 (closed). This is the issue's Phase 3, which it explicitly marked "optional, later" — filing it so the idea isn't lost, not because it's load-bearing.

Idea

buildMenuBar() (now in MainWindow_Menus.cpp, ~1,000 lines) and registerShortcutActions() (in MainWindow_Shortcuts.cpp, ~560 lines) are long imperative sequences of near-identical addAction(...) + connect(...) / registerAction(...) calls. Much of that repetition could collapse into a data table (id, label, shortcut, handler, enable-predicate) walked by a small builder loop.

Why it's optional / low priority

• Pure ergonomics — no behavior change, no architectural unlock, no bug.
• The decomposition already solved the actual pain (#3351's goal): these are now isolated in their own reviewable TUs, off the MainWindow.cpp hot path.
• Table-driving menus is a readability nicety with real risk of subtle behavior drift (action ordering, conditional enables, lambda captures) for modest payoff. Only worth doing if someone's already deep in the menu/shortcut code for another reason.

If pursued

• Start with registerShortcutActions() — it's the more regular of the two (the shortcut registry already has a uniform registerAction(id, name, category, …) shape).
• Menus are messier (submenus, separators, dynamic/conditional items, the contributors-fetch lambda) and may not table-drive cleanly — partial conversion is fine.
• Behavior-preserving; full menu-walk + shortcut QA required.

No urgency. Closeable as wontfix if the team decides the repetition isn't worth touching.

Refs #3351

Start with registerShortcutActions() in MainWindow_Shortcuts.cpp, then compare the related buildMenuBar() code in MainWindow_Menus.cpp. Review the existing registerAction and addAction/connect sequences before deciding what can be represented in a table. Done means behavior is preserved, including ordering, conditional enables, captures, and full menu and shortcut QA.