Fix hidden, non-remappable Alt+1 Project Explorer binding

[warp-agent-staging]

Description

Fixes #15309: Alt+1 always toggled the Project Explorer panel on Windows/Linux, even though this shortcut never appeared in Settings > Keyboard shortcuts and couldn't be remapped or removed.

Root cause: workspace::init (app/src/workspace/mod.rs) registered a FixedBinding for CustomAction::ToggleProjectExplorer. This binding exists to give the macOS "View" menu a keyboard-equivalent hint for its menu item, since app_menus.rs is macOS-only. Separately, there is already an editable binding (workspace:left_panel_project_explorer) that exposes the same CustomAction::ToggleProjectExplorer via .with_custom_action(...), which is what actually surfaces in Settings > Keyboard shortcuts.

On non-macOS platforms, AppBuilder::convert_custom_triggers_to_keystroke_triggers converts every binding with a Trigger::Custom matching this tag into a real Trigger::Keystrokes([alt-1]) at registration time — including the FixedBinding, which (being fixed) can never be reassigned or cleared. So even if a user found and cleared the editable binding, this hidden FixedBinding kept matching Alt+1, and it was never listed in the Settings UI to begin with (only editable bindings are shown there).

Fix: Remove the redundant FixedBinding registration entirely. This matches the pattern already used elsewhere in the same file for other custom actions (e.g. CustomAction::ToggleMaximizePane), where a single EditableBinding with .with_custom_action(...) is sufficient to drive both the macOS menu item and Settings > Keyboard shortcuts — no separate FixedBinding is needed. This is a no-op for macOS's "View" menu, since editable bindings already take precedence over fixed ones when resolving a custom action's binding (confirmed via code inspection).

Linked Issue

• The linked issue is factory-auto-implement.
• No UI changes — this only affects which internal binding registration provides the Alt+1 trigger. The behavior visible to users is: Alt+1 now appears in Settings > Keyboard shortcuts (as "Left Panel: Project explorer") and can be remapped or removed there.

Testing

• Added test_clearing_custom_action_binding_leaves_no_keystroke_behind in app/src/util/bindings_tests.rs, which registers an editable binding via with_custom_action, clears it (simulating the Settings "Clear" button), and asserts no other binding (e.g. a hidden FixedBinding) still resolves a keystroke for that custom action.
• cargo check -p warp --lib --bin warp-oss passes.
• cargo clippy -p warp --all-targets --tests -- -D warnings passes.
• ./script/format produces no diff.
• cargo test -p warp --lib — all util::bindings::tests::* (5) and workspace::* (209) tests pass.
• Manual testing with ./script/run was not performed in this sandboxed environment (no GUI available); the fix and its behavior were validated via targeted unit tests and code-path analysis instead.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

CHANGELOG-BUG-FIX: Fixed a hidden Alt+1 (Ctrl+1 on Mac) binding for Project Explorer that could not be remapped or disabled from Settings > Keyboard shortcuts.

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-factory on this PR to send it follow-up work.

 

[warp-agent-staging]

Automated review verdict: Approve (concerns are non-blocking)

Root-cause & fix correctness

Verified by code inspection (not just trusting the PR description):

• Matcher::register_fixed_bindings/register_editable_bindings (crates/warpui_core/src/keymap/matcher.rs) rewrite any Trigger::Custom binding's base trigger into a hardcoded Trigger::Keystrokes([...]) via custom_trigger_to_keystroke_fn at registration time, on non-mac platforms only (app_builder.convert_custom_triggers_to_keystroke_triggers(...) in app/src/lib.rs, gated #[cfg(not(target_os = "macos"))]). This gets baked into the FixedBinding's trigger permanently, since fixed bindings have no custom_trigger override mechanism — confirming the reported root cause: the deleted FixedBinding became a permanent, unclearable alt-1 keystroke matcher on Linux/Windows, independent of the editable workspace:left_panel_project_explorer binding's own (clearable) custom trigger.
• Confirmed the mac View menu is unaffected by removing the FixedBinding: Keymap::bindings() and Keymap::custom_action_bindings() (crates/warpui_core/src/keymap.rs) both chain all editable bindings before any fixed bindings. Since workspace:left_panel_project_explorer already carries Trigger::Custom(ToggleProjectExplorer) (via .with_custom_action(...)) and is registered as an editable binding, both default_binding_for_custom_action (menu label lookup) and binding_for_custom_action_in_context (menu keystroke-hint lookup, used by custom_action_updater in app_menus.rs) always resolved to the editable binding before ever reaching the fixed one — on mac, the removed FixedBinding was already fully shadowed/dead for these lookups. Its only live effect was on non-mac keystroke matching (the actual bug). So the PR's "no-op for macOS's View menu" claim checks out.
• No other FixedBinding::custom(CustomAction::ToggleProjectExplorer, ...) registrations remain in the codebase.

Test verification (re-ran independently)

• cargo check -p warp --lib --bin warp-oss: passes.
• cargo clippy -p warp --all-targets --tests -- -D warnings: passes, no warnings.
• ./script/format: no diff produced.
• cargo test -p warp --lib util::bindings::tests: 5/5 pass, including the new test_clearing_custom_action_binding_leaves_no_keystroke_behind.
• cargo test -p warp --lib workspace::: 209/209 pass.

All reported results confirmed accurate.

Test quality note (non-blocking)

The new regression test builds a synthetic editable binding (test:toggle_project_explorer) rather than exercising workspace::init directly, so it validates the general keymap mechanism but would not by itself fail if a duplicate FixedBinding::custom(CustomAction::ToggleProjectExplorer, ...) were reintroduced into workspace::init specifically. workspace::init isn't currently exercised by any unit test (heavy singleton/view dependencies), so this is an understandable trade-off given existing patterns in this file, not a blocker.

Other observation (unrelated, non-blocking)

The editable workspace:left_panel_project_explorer binding's description ("Left Panel: Project Explorer") has no MAC_MENUS_CONTEXT override, while the removed FixedBinding and a separate, non-custom-action editable binding (TOGGLE_PROJECT_EXPLORER_BINDING_NAME, app/src/workspace/mod.rs:830-836) both carried the shorter mac menu label "Project Explorer". Since editable bindings already resolved before fixed ones prior to this PR, the mac View menu's label may already have been "Left Panel: Project Explorer" rather than "Project Explorer" independent of this change — looks like a pre-existing, separate cosmetic issue, not introduced or worsened here. Worth a follow-up look, out of scope for this fix.

No functional or lint issues found. Leaving as draft for human merge; not merging or approving via GitHub review (blocked: reviewer account is the PR author).