Mouse support has issues when terminal does not support all modes.

Zellij requests the mutually exclusive mouse modes in order of least desired to most desired. https://github.com/zellij-org/zellij/blob/82f30e2cde5207e5b51301633686b2c7feac54f3/zellij-client/src/os_input_output.rs#L30

This relies on terminal emulators to ignore requests for unsupported modes and stay in the previous mode, which seems to be common behavior. In my instance, this works in Termux which doesn't support the any event mode (1003). However, mosh explicitly disables the previously enabled mode and only stores the most recent mode breaking this behavior. So when zellij sends the 1003 request it ultimately ends up disabling all mouse reporting.

I think this could be fixed by removing the explicit disabling of the current mode and storing all requested modes in the order requested so they can be played back in the right order on the client.

Testing

I tested the behavior of different mode requests via:

1. Open Termux -> mosh -> bash.
2. Run perl -E ' print "\e[?1002h\e[?1003h\e[?1006h" '
3. Move mouse (observe no characters printed).
4. Reset state: reset
5. Run perl -E ' print "\e[?1002h\e[?1006h" '
6. Move mouse (observe characters are print).

Repeating this outside of mosh printed character in step 3

Start with mosh's terminaldisplay.cc and reproduce the issue using the Termux → mosh → bash sequence and the Perl escape sequences listed in the report. Trace how mouse modes are stored and replayed; done means supported modes remain active when an unsupported mode is requested, with the reported mouse behavior reproduced correctly.