resolve keyboard shortcuts through one action table instead of a switch

The controls panel needs to say what each key does right now, and a panel that
keeps its own list of that is a list that goes stale. So the list moves into
lib/core/ControlAction.h: which actions exist, what each is bound to, and when
each does something. InputMapper stops deciding that and switches on the
resolved action instead, so the panel and the key handling cannot disagree
about what Q means -- there is only one place that says.

The table declares; it never performs. It holds no simulation access, fires no
events, and names nothing: display strings live in the ui target, which formats
the bindings this hands it, so a badge is rendered from the real binding rather
than typed beside it. What an action *does* stays exactly where it was.

ControlContext is the snapshot the rules read, which is what keeps this
testable without a world. Two of its facts come from BlueprintLibrary, which is
built after the world view and so arrives by setter; one comes from the new
hovered-transfer flag on BuildModeController, resolved once on mouse-move
through the same classifier the click and the ghost colour already use.

Behaviour is unchanged, deliberately. Ctrl still separates the chords and every
other modifier is still ignored, so Shift+A pans as before; matching modifiers
exactly would have silently swallowed those presses. Build hotkeys and F3/F4
stay outside the table -- the first are advertised on the build buttons and
already derive their badges from the handler's own table, the second are
development controls the panel must never offer.

The tests are the point of putting this in lib: every row's bindings must
resolve back to that row's action in that same context, which fails the moment
a shown row and its handler part ways.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHcUerKAZKWNvSKJxYKbnG

src/ui/InputMapper.h

@@ -3,14 +3,19 @@
 #include <QString>
 
 #include "BuildingType.h"
+#include "ControlAction.h"
 #include "WorldCamera.h"
 
 class QKeyEvent;
 
 // Turns raw key events into the game's semantic actions and publishes them
 // (REQ-UI-HOTKEYS). Widgets react to the action, never to the key, so the two can
-// be rebound independently later; the bindings themselves are still hard-coded
-// here for now.
+// be rebound independently later.
+//
+// Which key means what is not decided here: the caller hands in a ControlContext and
+// ControlAction.h resolves the press against it, so this file only knows what each
+// action means once resolved. That is what keeps the controls panel and the key
+// handling from drifting apart -- both read the one table (REQ-UI-CONTROLS-ACCURACY).
 //
 // Two output shapes, chosen by the nature of the action rather than by taste:
 //
@@ -34,9 +39,10 @@ public:
     static QString getBuildHotkeyLabel(BuildingType type);
 
     // Both return true when the key was consumed; the caller passes anything else
-    // on to its base class so unrelated shortcuts keep working.
-    bool handleKeyPress(QKeyEvent* event);
-    bool handleKeyRelease(QKeyEvent* event);
+    // on to its base class so unrelated shortcuts keep working. `context` is the
+    // player's current situation, which decides what a key does (REQ-UI-CONTROLS-CONTENT).
+    bool handleKeyPress(QKeyEvent* event, const ControlContext& context);
+    bool handleKeyRelease(QKeyEvent* event, const ControlContext& context);
 
     // Drops all held-key state, publishing the resulting change. Call when the
     // receiving widget can no longer expect key-up events.