fix(terminal): honor Num Lock for keypad navigation

[malekelkssas]

What changes

• Preserve GTK's translated keypad navigation key when forwarding key events to embedded Ghostty. Without this mapping, Ghostty sees the physical keypad digit even when Num Lock is off.
• Keep keypad digits unchanged when Num Lock is on.
• Add a regression test for the keypad navigation mappings and the Num Lock on digit case.

Reproduction

On KDE Plasma Wayland with Limux 0.1.30, turn Num Lock off and press keypad 1 in a terminal prompt. Limux types 1, while Konsole treats the same key as End.

Verification

• ./scripts/check.sh passed on the clean base and after the change.
• Tested a patched Limux host on the affected machine: keypad 1 acts as End with Num Lock off and types 1 with Num Lock on.

[bvolpato]

The Num Lock-off behavior you tested makes sense. One compatibility edge: mapping KP_End to keycode 115 makes embedded Ghostty see ordinary End, not keypad End. That changes keybind matching and Kitty keyboard sequences for apps that distinguish keypad keys; Ghostty's GTK host keeps this as numpad_end. Can we preserve keypad identity while producing navigation? The embedded API only accepts a native keycode today, so this may need follow-up there. I would not block this fix on that edge alone, but wanted to make the tradeoff explicit.