feat(gui): expose the Fn-lock toggle in the Device tab

[4ni1ak]

Summary

• fn_lock: Option<bool> and its agent-side write path (apply_fn_locks in the orchestrator, driving HID++ 0x40a2/0x40a3) already exist, but nothing in the GUI could set it — I grepped all of openlogi-desktop and found zero references to fn_lock before this change. See [Feature]: MX Keys键盘功能区按键映射太少 #1310 (the linked comment specifically asks for "Fn+Esc toggle for hardware Fn-Lock").

Changes

• crates/openlogi-core/src/config.rs: Config::set_fn_lock accessor, mirroring the existing set_invert_scroll/set_dpi_presets pair (fn_lock's reader already existed).
• crates/openlogi-desktop/src/state/fn_lock.rs (new): AppState::current_device_supports_fn_lock/current_fn_lock/commit_fn_lock, following the same shape as state/scroll.rs's invert_scroll wiring.
• crates/openlogi-desktop/src/app/detail.rs: a Fn-lock Switch row in the Device tab's existing configuration card, shown only when the active device is a keyboard.
• crates/openlogi-ui/locales/*.toml: two new keys (device.fn_lock, device.fn_lock_description), added at the same position in every catalog; non-English catalogs carry the English text pending Crowdin translation.

Scope

This only covers the Fn-lock toggle. The other two asks in #1310's comment (Fn as a live chord modifier for custom shortcuts, and independent F13–F19 press vs. Fn+press overrides) are much larger — new OS-hook-layer work and a real product-design question respectively — and are intentionally left out of this PR.

Testing

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace (all green, including a new test in state::fn_lock::tests covering the default-false/toggle round trip)
• cargo test -p openlogi-ui locale (catalog parity) and cargo test -p openlogi-desktop i18n
• cargo doc --workspace --no-deps --document-private-items (excluding the GPUI crates)
• Not visually verified — no safe display available in this environment to screenshot the new toggle. A maintainer/reviewer should confirm it renders and round-trips through config.toml before merging.

Fixes #1310

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the previously reported unsupported-keyboard behavior is fixed by capability-based gating, with no new actionable defects identified.

Summary

The PR exposes the existing Fn-lock configuration through the desktop Device tab and now advertises support only when the keyboard reports a compatible HID++ feature.

• Adds capability detection for HID++ 0x40a2 and 0x40a3.
• Persists Fn-lock changes and requests an agent configuration reload.
• Adds the capability to IPC serialization and advances the protocol version.
• Adds localized labels and state-level coverage for supported and unsupported keyboards.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Enumerate HID++ features] --> B{0x40a2 or 0x40a3?}
    B -->|Yes| C[Capabilities.fn_lock = true]
    B -->|No| D[Capabilities.fn_lock = false]
    C --> E[DeviceRecord capabilities]
    D --> E
    E --> F{Fn-lock supported?}
    F -->|Yes| G[Render Device-tab switch]
    F -->|No| H[Hide switch]
    G --> I[Persist Config.fn_lock]
    I --> J[Reload agent configuration]
    J --> K[Apply Fn-lock to hardware]

Loading

_{Reviews (2) · Last reviewed commit: "fix(gui,core,ipc): gate the Fn-lock togg..."}