Support context filtering for commandMenu parent items in custom commands

### Is your feature request related to a problem? Please describe.

Currently, when using `commandMenu` in custom commands, the parent menu item always appears globally across all panels. The `context` field only applies to individual child commands within the menu, which means the menu is filtered at runtime - child commands that don't match the current context are hidden from the menu.

This creates a suboptimal UX when you want a submenu that's only relevant to a specific panel. For example, I want a merge operations submenu (SHIFT+M) in the commits panel to merge a selected commit into the current branch, but I don't want this menu appearing in other panels like files or status.

### Describe the solution you'd like

Allow the `context` field on `commandMenu` parent items to control which panels display the menu keybinding, similar to how regular custom commands work.

```yaml
customCommands:
- key: M
context: commits,subCommits # Menu only visible in commits panels
description: Merge operations
commandMenu:
- key: m
command: git merge --no-ff {{.SelectedCommit.Hash}}
description: Merge commit (--no-ff)
```

This would make the SHIFT+M keybinding only register in the specified contexts.

### Describe alternatives you've considered

1. **Current workaround:** Accept the global menu and rely on runtime filtering - the menu appears everywhere but shows "No applicable commands in this context" when opened in wrong panels
2. **Separate keybindings:** Skip the submenu and use individual keys for each operation - loses the organizational benefit of menus
3. **Override built-in keybindings:** Use keybinding overrides to add functionality to existing context-specific menus - only works if a suitable built-in menu exists

### Additional context

Looking at `pkg/gui/services/custom_commands/client.go:35`, commandMenu parents are hardcoded with `ViewName: ""` (global binding). The context filtering happens inside `showCustomCommandsMenu()` at lines ~58-65 by checking the current view at runtime.

I'm interested in implementing this feature if the maintainers are open to it. The change would involve:
1. Allowing `context` field on commandMenu parent items during validation
2. Using the context to set appropriate `ViewName` in the binding instead of empty string
3. Maintaining backward compatibility by defaulting to global when context is omitted