Describe the bug
Using the official vim-style key config (https://github.com/gitui-org/gitui/blob/master/vim_style_key_config.ron) directly causes a keybinding conflict.
Shift+U is defined as reset in the config file, but GitUI also keeps its default binding for undo_commit.

As a result:

• In Unstaged Changes, Shift+U works as reset (expected).
• In Staged Changes, the same key instead triggers undo last commit.

Both actions show similar confirmation prompts, which makes it easy to mistake one for the other and accidentally undo a commit.

As a user, I’m not sure whether mapping the same key to different actions in Unstaged vs Staged windows is intended design, but I did make this mistake multiple times in real use.

To Reproduce

1. Use the official vim_style_key_config.ron without modification
2. Go to Unstaged Changes → press Shift+U → file reset (expected)
3. Go to Staged Changes → press Shift+U → undo last commit (unexpected)

Expected behavior
When using the official config, Shift+U should only perform reset.
undo_commit should be reassigned to another key to avoid conflict.

Screenshots
N/A

Context (please complete the following information):

• OS/Distro + Version: Windows 10
• GitUI Version: 0.27.0 (99f6967) 2025-01-14
• Rust version: cargo 1.89.0 (c24e10642 2025-06-23)

Additional context
This issue happens specifically because the officially provided config file conflicts with default keybindings.
A simple workaround is to explicitly rebind undo_commit to another key in the config, e.g.:

undo_commit: Some(( code: Char('_'), modifiers: "SHIFT")),

This avoids the conflict while keeping Shift+U for reset.