fix(core,device,i18n): add K380 MultiPlatform F4-F7 as rebindable keyboard keys

[4ni1ak]

Summary

• Adds four new rebindable keyboard keys for the Logitech K380's F4-F7 row, which use the 0x1b04 MultiPlatform Home/App Switch/Menu/Back task family and were previously invisible to OpenLogi's binding system.

Changes

• crates/openlogi-core/src/binding/button.rs: added ButtonId::KeyHome, KeyAppSwitch, KeyMenu, KeyBack (appended at the end of the enum per its append-only wire contract), with label()/translation_key() arms and entries in KEYBOARD_KEYS.
• crates/openlogi-core/src/binding/defaults.rs: added the four new variants to the existing native-passthrough (Action::None) default arm alongside the other keyboard keys.
• crates/openlogi-device/src/session/keyboard.rs: added the four new CID → ButtonId entries to KEYBOARD_KEY_CIDS (0x00bb → Home, 0x00ba → App Switch, 0x00bc → Menu, 0x00bd → Back), matching the task IDs in the official x1b04_tasks_ids_list (0x97, 0x96, 0x98, 0x99).
• crates/openlogi-ui/locales/*.toml (all 23 locales): added keyboard.home_key, keyboard.app_switch_key, keyboard.menu_key, keyboard.back_key with translated values.

Testing

• cargo check --workspace
• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace
• RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --document-private-items --exclude openlogi-ui --exclude openlogi-desktop --exclude openlogi-overlay --exclude openlogi-agent
• cargo test -p openlogi-ui locale (catalog parity)
• cargo test -p openlogi-desktop i18n (typed translation key resolution)
• Not runtime-tested on a physical K380 — CID/task-ID mapping is cross-checked against the reporter's openlogi diag controls output on issue [Device]: K380 action buttons (F4-F7) could not be remapped #1010 and against the official x1b04_tasks_ids_list, but real-hardware verification of the F4-F7 remap behavior is still the maintainer's/reporter's job.

Fixes #1010

[greptile-apps]

Confidence Score: 4/5

The PR should not merge as the complete K380 remapping fix because users cannot assign actions to the new HID++ controls through the keyboard UI.

Findings

1.  Remapping UI remains disconnected ▶

Summary

This PR defines four K380 MultiPlatform controls, maps their HID++ CIDs, preserves native behavior by default, and adds localized labels. The device-side mapping is internally consistent, but the new logical controls are not connected to the desktop keyboard-remapping path.

• Appends four ButtonId variants without renumbering existing serialized variants.
• Maps K380 CIDs 0x00ba–0x00bd to the corresponding logical controls.
• Adds complete locale coverage and native-passthrough defaults.
• Leaves the UI's global KeyTrigger bindings disconnected from the per-device ButtonId bindings consumed by HID++ capture.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    UI[Desktop F4-F7 controls] --> KT[Global KeyTrigger bindings]
    KT --> KC[config.keyboard.bindings]
    HID[K380 CIDs 0x00ba-0x00bd] --> BID[New ButtonId variants]
    BID --> DC[Per-device ButtonId bindings]
    DC --> CAP[HID++ wanted map and diversion]
    KC -. no conversion or bridge .-> CAP

Loading

_{Reviews (1) · Last reviewed commit: "feat(core,device,i18n): add K380 MultiPl..."}

[greptile-apps]

Remapping UI remains disconnected

Adding these variants to KEYBOARD_KEYS does not expose them in the keyboard remapper. The UI still creates global KeyTrigger bindings for fixed F4–F7 keycodes, while the HID++ capture path looks for the new ButtonId values in the selected device's per-device bindings. As a result, selecting F4–F7 in the UI never adds KeyHome, KeyAppSwitch, KeyMenu, or KeyBack to the capture map, so users cannot configure these new K380 controls through the advertised remapping UI.

Knowledge Base Used: Core domain and configuration