Ctrl+Shift+letter collapses to Ctrl+letter ; xterm modifyOtherKeys (ESC[>4;2m) is ignored

Environment: rioterm Version 0.5.28 (0.5.28.20260917201501), macOS (Apple Silicon), TERM=rio, tmux 3.7c.

1. Symptoms

• Outside tmux, cat -v shows Ctrl+F and Ctrl+Shift+F both as ^F. After printf '\e[>4;2m', still ^F^F. So xterm modifyOtherKeys enable has no effect.
• Outside tmux, apps using the Kitty keyboard protocol (e.g. pi sending ESC[>7u) work: Ctrl+Shift+F arrives as ESC[102;6u.
• Inside tmux, Ctrl+Shift+F never reaches the inner app: with extended-keys on, extended-keys-format csi-u, and terminal-features ",rio*:extkeys", inner pane_key_mode becomes Ext 2 but cat -v after ESC[>4;2m still shows ^[[102;5u^[[102;5u (both as Ctrl+F). Ghostty in the same tmux setup reports ^[[102;5u vs ^[[102;6u and works.
• Practical impact: pi transcript search (ctrl+shift+f) works in rio outside tmux and in ghostty+tmux, but not in rio+tmux.

1. Possible cause

• Rio appears to implement Kitty keyboard handling (kitty_keyboard.rs) but ignores the xterm modifyOtherKeys enable/disable sequences (ESC[>4;1m, ESC[>4;2m, ESC[>4;0m).
• tmux only ever requests extended keys from the outer terminal with xterm mode 2 (Eneks=\E[>4;2m, see tmux 3.5 CHANGES: "always request mode 2 from parent terminal"); it never sends a Kitty push (ESC[>...u) outward. It does accept both CSI 27 ~ and CSI u from the outer terminal.
• So tmux can never put Rio into extended mode: tmux sends >4;2m, Rio ignores it and keeps sending legacy 0x06, tmux forwards it as Ctrl+F. Ghostty works only because it sends CSI-u unsolicited.
• Suggestion: support the xterm modifyOtherKeys enable sequences in Rio (at least >4;1m / >4;2m / >4;0m), or document that Rio is Kitty-only so multiplexers like tmux cannot drive it via the xterm path.