fix(remote): accept the history marker glued to a row on tmux before 3.2

tmux before 3.2 prints no newline after `capture-pane -p` output, and
`-J` leaves the history's last row unterminated when the screen starts
inside a wrapped line. The marker row printed next is then glued onto
that row (`...first half<marker>\n31\n...`). The parser took the marker
only as a whole row, so it returned null and every load fell back to
the local capture while the screen stayed that way. Debian 11, Ubuntu
20.04 and RHEL 8 ship tmux 3.1c, 3.0a and 2.7.

The parser now takes the first `<marker>\n` wherever it ends a row (the
marker is random per read, so no row the pane holds ends with it) and
re-terminates a history that lacks its newline. A tail -c cut still
drops only the history's partial first row, now decided on the whole
output, so a cut inside the one row the marker is glued to leaves no
history instead of losing the marker. dropPartialFirstRow, no longer
called, is removed.

Docs and the findFrameInScreen JSDoc also say the splice does not place
the frame of an agent TUI mid-turn (a live region pinned to the bottom,
new rows inserted above it), which falls back to the history-over-frame
join.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/remote-sessions.md

@@ -290,7 +290,11 @@ would REPEAT the rows between it and the true one, so a shorter overlap (a lone
 `$` row that happens to match after a spinner row changed) is not trusted.
 When the frame cannot be placed (more output scrolled than the screen held, or
 nothing matches), the join is history over frame, as without the screen read.
-What is left: when the screen repeats a whole block of rows, the frame can be
+That includes an agent TUI mid-turn (Claude Code, codex, opencode): it keeps a
+live region (spinner, composer, footer) pinned to the bottom and inserts new
+rows above it, so the frame is not a shifted copy of the screen and is not
+placed. A plain shell places. What is left: when the screen repeats a whole
+block of rows, the frame can be
 placed at the higher copy, which leaves out the rows between the two copies.
 
 The history, the history size and the screen are ONE tmux command list
@@ -302,7 +306,10 @@ those milliseconds were in neither capture (measured with output streaming: 1-2
 rows per load on a LAN host, every read on a local busy pane). This rests on how
 tmux's command queue behaves, not on a documented guarantee. A random marker row
 (`display-message`) separates the history from the size and the screen, since
-tmux output cannot carry the NUL markers around it. The remote `tail -c` bound
+tmux output cannot carry the NUL markers around it. tmux before 3.2 prints no
+newline after `capture-pane -p` output, so when the history ends inside a
+wrapped line the marker is glued onto that row; the parser accepts the marker
+at the end of a row and re-terminates the history. The remote `tail -c` bound
 applies to that whole output, history first, and is the configured byte cap
 plus 1 MiB for the marker, size and screen, so a cut lands in the history; the
 route trims what it returns to the cap itself.