fix(web): 170px of chrome above the output, and a switch that showed the other pane

Three things, all measured at 390x844 rather than read off the CSS.

The chrome above a session was 170px, 20.1% of the phone, before a line of a
pane had rendered. 69px of app header -- of which the session view covered the
bottom 20, its `top` a hardcoded 49px against a header sized by a 44px button,
so both header buttons were clipped through the whole of a session -- then 55px
of session header, itself 55 because `back` carried a 1.4rem font-size around a
20px icon, text metrics for a button with no text in it. It is 116px, 13.7%:
the header is a height (`--header-h`, the one place the number is written and
what `.terminal-view`'s top is computed from, so they cannot drift again) and
the session header pins every child to 28px, the rule the history bar already
runs on.

The two sibling levels share one row. They were two rows of 33px and 4 of the
10 agent panes measured paid for both -- for a row that is at most three chips
beside a row that is at most five. The outer row takes the overflow, the border
and `overscroll-behavior`; the groups keep their ids, their aria-labels and
their own "hidden when it holds no choice" rule, with a 1px rule between them
drawn only when both are there. A rebuilt strip loses its scroll position, so
`scrollSibsToOpenPane` puts the pane chip back on screen -- after the view is
displayed, since renderSiblings runs while every rect is still zero.

And a switch empties the mirror. Until the new pane's read lands -- a relay
round trip, an SSH hop on a remote host -- the buffer on screen was the output
of the pane you LEFT, under the new title and beside its filled chip. `__mirror`
goes with it, and so does any range inside that output: `selectionInside` cannot
tell a stale drag from a live one and would have refused the new pane's first
read. Only on a real switch -- openTerminal is re-entered on every `blocked`
event for the pane already in front of you.