sl0p: route mouse rename through the server, fixing stuck rename mode

Enter/Esc still did not leave rename mode after entering it by double-click.

The previous attempt fixed a real trap (a None base_mode makes
change_to_default_mode a silent no-op) but not this one. The actual cause:
zellij tracks the client's input mode in TWO places.

  - Screen's ModeInfo, which drives what is rendered.
  - SessionData::current_input_modes on the server, which is what ROUTES key
    input to the right handler.

The double-click path sent ScreenInstruction::ChangeMode directly, so only the
first was updated: the rename prompt appeared and accepted text, while the
server still interpreted keys in the previous mode - so Enter and Esc were
never treated as rename-mode keys and there was no way out.

Action::SwitchToMode (the rename keybind) sends ServerInstruction::ChangeMode
instead, and the server handler updates current_input_modes AND derives
base_mode from the session config before forwarding to Screen. The mouse path
now sends exactly that, so it is the same code path as the keybind rather than
an imitation of it.

Tab::client_base_mode is dropped: the server supplies base_mode correctly, so
it is no longer needed.

Lesson worth keeping: 'send the instruction the existing feature sends' beats
reconstructing its effects downstream. Both bugs here came from entering the
system one layer too low.

Baselines held: zellij-server 1429/30.

0 files changed, 0 insertions, 0 deletions