Allow tab navigation without leaving Navigate mode

[Angel-O]

Navigate mode supports movement at two levels of Herdr's hierarchy:

• navigate_workspace_up / navigate_workspace_down select a workspace
• navigate_pane_left / navigate_pane_down / navigate_pane_up / navigate_pane_right select a pane

There is no equivalent Navigate-mode action for selecting the previous or next tab. The normal previous_tab, next_tab, and switch_tab bindings cut off the continuous Navigate-mode flow. Literal Tab is also prohibited as a Navigate-mode binding.

#1850 fixed Navigate mode exiting after the first pane-focus movement, but tab switching remains a missing level between workspaces and panes.

Proposed behavior

Add configurable Navigate-mode tab actions, for example:

[keys]
navigate_tab_previous = "shift+left"
navigate_tab_next = "shift+right"

The exact defaults are flexible, but invoking either action should switch tabs while keeping Navigate mode active, just as workspace and pane movement now do.

Why

Herdr navigation is hierarchical:

workspace -> tab -> pane

A keyboard user should be able to enter Navigate mode once, move to a workspace, select one of its tabs, then select a pane before explicitly accepting or cancelling. Currently the middle step is unavailable, so selecting a different tab interrupts the flow and requires re-entering Navigate mode.

This would complete continuous keyboard navigation across all three structural levels without changing existing bindings. The actions should be configurable so users can choose keys that do not conflict with their pane-navigation layout.

Originally filed as #2076 before the automated guidance clarified that feature requests belong in Discussions.

[Angel-O]

A clarification on the natural bindings: Tab already performs tab navigation while Navigate mode is open, but doing so exits Navigate mode and cuts off the continuous navigation flow.

The most natural behavior would therefore be:

• Tab: move to the next tab and remain in Navigate mode
• Shift+Tab: move to the previous tab and remain in Navigate mode

This would preserve the existing Tab interaction rather than introduce unrelated shortcuts, while completing the workspace -> tab -> pane navigation hierarchy. The current config validation restrictions around tab/shift+tab for generic Navigate-mode movement fields should not dictate the UX for dedicated tab-navigation actions.