fix(keymap): layer vscode keymap on macos when target is macOS (#1916)

[sinelaw]

Summary

Fixes #1916. The vscode built-in keymap only adds 4 Ctrl-based overrides on top of the shared default keymap, so on every platform users get the Linux/Windows VSCode conventions. The most visible breakage on macOS:

• Alt+Right (Option+Right) → navigate_forward instead of move_word_end
• Alt+Left (Option+Left) → navigate_back instead of move_word_left
• Ctrl+B → unbound (default uses different mapping) instead of toggle_file_explorer

The maintainer's fix sketch in the issue suggests making vscode inherit macos on macOS — that's what this PR does. The macOS-specific bindings for Alt+Left/Right, Ctrl+B, etc. already live in macos.json; layering vscode on top means Mac users get Mac VSCode conventions, while the 4 Ctrl-based vscode overrides still win where they apply.

Implementation

load_builtin_keymap is split into a thin wrapper plus load_builtin_keymap_for_target(name, is_macos) so the platform-conditional rewrite ("vscode"'s inherits becomes "macos" when is_macos is true) is testable from any host. Production callers continue to use cfg!(target_os = "macos").

Test plan

Four new unit tests in config::tests:

• test_vscode_keymap_inherits_macos_on_macos — direct check on the loaded keymap
• test_vscode_keymap_inherits_default_on_non_macos — non-regression on Linux/Windows
• test_vscode_keymap_on_macos_resolves_option_right_to_word_end — end-to-end resolution through resolve_keymap, confirms Option+Right lands on move_word_end
• test_vscode_keymap_on_non_macos_resolves_alt_right_to_navigate_forward — end-to-end resolution preserves Alt+Right → navigate_forward on non-macOS

Verified the macOS-target tests fail before the fix (Got: Some("navigate_forward") vs expected Some("move_word_end")) and pass after — satisfies CONTRIBUTING.md's "fails without fix, passes with fix" requirement.

Also ran:

• cargo fmt --check
• cargo clippy -p fresh-editor --lib --tests --no-deps (no new warnings introduced)
• cargo check -p fresh-editor --all-targets --features gui (GUI feature builds)
• Full config::tests:: and input::keybindings:: test modules
• Manual smoke test: launched target/release/fresh in tmux with active_keybinding_map: vscode — editor starts cleanly, Alt+Right is unchanged on Linux as expected

Scope notes

This only addresses the terminal/Option+Left/Right half of #1916. The Cmd+B half is acknowledged in the issue as overlapping with the long-known macOS-terminal Cmd-key delivery problem (#356, #219) — a vscode user on fresh-gui who wants Cmd shortcuts can still pick macos-gui directly; if a future PR wants vscode-on-GUI to inherit macos-gui, the GUI auto-select in gui/mod.rs can be extended.

https://claude.ai/code/session_01S7vceisnAN96RWdKPFdTGt

---

Generated by Claude Code

[sinelaw]

Maybe we should just udpate the macos keyboard map directly without needing the vscode map at all in this case? i.e. for the specific keys the user complained about, update macos map