The log cannot be scrolled or filtered by keyboard

[wallstop]

DISCLOSURE: LLM-GENERATED TEXT

Problem

The log cannot be scrolled by keyboard, and cannot be filtered. The
command line owns panel focus for the entire time the console is open,
so Page Up, Page Down, Shift+Home, and Shift+End never reach the log
view.

The complete key handling in the package is:

• Runtime/CommandTerminal/UI/TerminalUI.cs:2403 - one KeyDownEvent
  handler on the command field, for paste.
• Runtime/CommandTerminal/UI/CommandPaletteUI.cs:1216 - the palette's
  switch on Down, Up, Return, Escape, Tab.
• Runtime/CommandTerminal/Input/TerminalKeyboardController.cs:94 -
  the eight polled controls: Close, EnterCommand, Previous, Next,
  ToggleFull, ToggleSmall, CompleteBackward, CompleteForward.

No WheelEvent, ScrollTo, or scrollOffset handler exists in
TerminalUI.cs; the only ScrollTo call in the package is the
palette's row scroll.

Evidence

Styles/BaseStyles.uss:32 - the scrollbar is 10px wide. That and the
mouse wheel are the only ways to move the log.

Why it matters

With the default 256-entry buffer and Unity log forwarding on, a
developer looking for one error has to drag a 10px bar or read every
line. There is no grep or filter, and no way to jump to an error.

#194 makes the tail detach when the developer scrolls away, which
makes "park the view and read" a first-class state. It gives no other
way to move: to get back to the tail you have to wheel all the way
down.

Shape of a fix

• PageUp/PageDown on the log, and a Home/End pair that reaches
  the end (which is also the "re-attach" gesture).
• A filter over the log, ideally paired with a jump-to-next-match key
  pair so it does not become a second scrolling problem.
• Either way, the input has to reach the log while the command line
  holds focus, so the command field's KeyDownEvent needs to route
  these rather than swallow them. PlayerInput toggle actions fire while a console field has focus #178/Let a focused text field keep the character a hotkey types #174 already made the field
  yield to the engine for character keys, so this extends that
  contract rather than inventing one.

Acceptance

With the console open and 256 buffered lines, a developer can page
through the log, jump to its end, and filter to a substring - from the
keyboard alone.

[wallstop]

DISCLOSURE: LLM-GENERATED TEXT

Landed in #201

The movement half of this issue. Page Up and Page Down page the log by one
viewport, and Ctrl+Home / Ctrl+End reach its oldest and newest lines, routed
from the command field's key handler because the command line holds panel
focus for as long as the console is open. Home and End without the modifier
stay with the command line, where they move the caret as a text field should.

Two decisions worth stating:

• The command modifier rather than bare Home/End. Those keys move the caret in
  a one-line field and a developer editing the command they are about to run
  needs that. Page Up/Page Down were free - a one-line field has nothing to
  page - and the document-scoped pair was not.
• Paging back detaches the tail exactly as scrolling back does, so new output
  does not pull the view to the end while it is being read. Ctrl+End is the
  way back to following, and a page that reaches the end leaves the log
  following rather than parked a line short of a growing end.

LogScrollKeys holds the decision and is engine-independent; LogTailFollower
gained a Detach(position, extent) for the one move it cannot infer, which
is the window between running a command and the terminal's next pin.

Not landed

The substring filter and its jump-to-next-match pair. A filter that hides
lines has to say so in the view, decide what a "match count" means for the
tail follower, and offer a way out that is not typing a different filter.
That is its own change and is recorded in PLAN.md as the next item.