/btw overlay opens scrolled to bottom; j/k scroll keys not supported

Summary

The /btw overlay has two separate UX issues when the response is long enough to require scrolling:

1. Overlay opens scrolled to the bottom instead of the top

After /btw finishes processing a multi-screen response, the viewport is anchored at the end of the answer. To start reading, I have to scroll all the way back to the top first. The natural reading flow is top → bottom, so the overlay should open with the scroll position at the top of the response.

2. j / k scroll keys are not supported

The footer shows ↑/↓ to scroll as the only scroll bindings. The rest of the Claude Code CLI (transcript view, history navigation, etc.) accepts vim-style j/k for vertical movement. The inconsistency breaks muscle memory — I instinctively press j/k in the /btw overlay and nothing happens. Suggested fix: alias j → ↓ and k → ↑ inside the /btw overlay.

Screenshot

!btw overlay scroll feedback

In the screenshot, you can see the highlighted /btw prompt is at the top of the response, but on initial render the overlay scrolled past the entire answer and landed at the bottom. The footer shows ↑/↓ to scroll · f to fork · x to clear history · Esc to close — note no j/k.

Expected behavior

1. /btw overlay opens with scroll position at the top of the new response.
2. j and k work as scroll keys alongside ↑ / ↓.

Environment

• Claude Code: 2.1.152
• OS: macOS 26.5 (build 25F71)
• Terminal: Ghostty (running inside tmux, TERM=tmux-256color)
• Shell: zsh
• Model: Opus 4.7 (1M context)