Tab walks the panel, and a press puts the caret where it lands

[tannevaled]

toolkit v0.277.0 lets the focus walk into a ScrollView and a FormField. Neither
implemented focusableChildren, so a control inside a scrolling panel — which is
where every control in this workbench lives — was invisible to it, and Tab
reached nothing. Reaching them is only half of it: a child's Bounds do not move
when the view scrolls, so the walk hands back the controls below the fold too,
and the release scrolls the focused one into sight rather than leaving a cursor
blinking where nobody can see it.

The workbench's own routing stays. The toolkit walk now reaches these controls,
but this still addresses the box it built and last saw pressed, because that is
also what decides who an arrow key belongs to.

AND A BEHAVIOUR CHANGE THIS HAD NOT NOTICED

Bisecting the toolkit between v0.272.0 and v0.277.0 found the Marks panel test
failing from v0.273.0, four releases before anything of ours. It is not a
regression: v0.273.0 made a press put the caret WHERE IT LANDS instead of after
the last letter, which is what a text box should do. These rows are pressed in
the middle, and for a box that already holds a default that lands before the
text — so typing "!" into the watermark gave "!DRAFT" rather than "DRAFT!".

typeInto now sends the caret to the end first, which is what somebody adding to
what is already there does. The test was encoding the old behaviour, not the
intended one.

A hazard looked at and NOT acted on: focusClick hit-tests with surface
coordinates against Bounds that do not move when a view scrolls, so calling it
directly on a scrolled view picks the wrong row — row 1 for a press five rows
down. Through the real path it is masked: ScrollView.OnEvent translates the
press and the child takes the caret itself, and a test that goes that way passes
before the change as well as after. Nothing is shipped for it, because nothing
demonstrates it.