feat(tui): return to the scrolled-up position on messages_first - #53630

Note: I'm aware v1 is now the maintenance branch and new features go to v2 only. This PR is here for others who want to use it on v1. I will submit a v2 version once I've migrated my plugin setup to v2.

Issue for this PR

Closes #53629. Builds on #53333: this branch contains that PR's commit too. Review only the last commit, 78ce706 "return to the scrolled-up position on messages_first". It is stacked because it uses #53333's ctrl+home / ctrl+end bindings and drops its mark from that PR's navigation commands.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

messages_last (end, ctrl+end) now remembers where a scrolled-up reader was. The next messages_first (home, ctrl+home) brings them back there instead of to the top, and a second messages_first goes to the top as before. So end then home is a round trip, and home home still reaches the top.

The mark is the renderable at the top of the viewport plus its offset from that edge. Restoring scrolls that renderable back to the same row, so the position stays correct when content above or below it changes. It is a renderable rather than a scroll offset or a part id: offsets drift as content changes, and apply_patch repeats its part id across one box per file.

The mark is dropped, and messages_first goes to the top, when:

• it was taken in another session;
• the view is no longer at the bottom when messages_first runs (dragged scrollbar, anything else that moved it);
• any other navigation command ran in between (page, half page, line, prompt, landmark, block, last user message), or the wheel scrolled the transcript (onMouseScroll on the scrollbox);
• its renderable is destroyed or no longer in the transcript, for example after a revert or when the oldest messages are trimmed.

messages_last pressed while already at the bottom keeps the mark it holds, so new output or a submitted prompt in between doesn't lose it. A view sitting at the bottom is following output, so restoring from there doesn't interact with sticky scroll, and new output arriving afterwards above the restored view is handled by the existing layout code like any other scroll-up.

The rules live in rememberScroll / recallScroll in src/routes/session/navigation.ts, generic over the anchor type so they are unit-testable without a renderer. The route keeps one scrollReturn variable.

How did you verify your code works?

• test/routes/session/navigation.test.ts covers the state machine: remember on leaving a scrolled-up view, replace on leaving again, keep when already at the bottom, discard across sessions, recall only at the bottom and only in the same session. bun test and bun typecheck pass in packages/tui.
• In a throwaway tmux socket with isolated XDG_* dirs and a 28-message imported session, sending keys with tmux send-keys (first viewport row after each key):

# scrolled up, end, home returns, home again goes to the top
C-S-Down | # Questions
C-End    | # Todos              <- bottom
C-Home   | # Questions          <- back
C-Home   | PROMPT 1: please do step 1

# end, then any navigation drops the mark
C-End    | # Todos
C-Up     | PROMPT 6: please do step 6
C-Home   | PROMPT 1: please do step 1

# end, line up and back down to the bottom: dropped
C-End    | # Todos
M-C-y    |
M-C-e x3 | # Todos
C-Home   | PROMPT 1: please do step 1

# end at the bottom keeps the mark; end, home toggles
C-End    | # Todos
C-End    | # Todos
C-Home   | FINAL 1: step 1 is done.
C-End    | # Todos
C-Home   | FINAL 1: step 1 is done.

With the view three rows into a response before ctrl+end, ctrl+home restores all 30 captured viewport rows byte for byte. On dev, home after end goes to the top.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

This PR is AI generated, but under direct supervision and on request of @Nowaker.