Rebuild the terminal's keypad, and fix what a device run showed

Six defects, all found by running this head on an emulator against a local API rather than by reading it.
They are in one commit because two of the files carry several of them and splitting those would mean
hand-editing patches; each is argued at its own site.

── the keypad, which is most of this ───────────────────────────────────────────────────────────────────
It was eleven 30-by-44 keys in a horizontal ScrollViewer, and it was wrong twice over. A pan and a press
begin with the same few pixels of travel, so a thumb coming down at an angle — which is how a thumb comes
down — was read as the start of a pan and the press was never delivered; the row slid slightly instead.
And 30 tall is well under the 48 Android asks for, so the presses that did arrive were hard to aim. The
arrows, the keys pressed most and in sequence, were the ones parked past the right-hand edge.

Termux, Termius, JuiceSSH, ConnectBot and Blink all ship this row and not one of them scrolls it: they
divide the width evenly and add a second row when the set does not fit. That is not convention for its own
sake — a key whose position is fixed can be hit without looking, which is the whole point of a modifier row
used while reading the output above it.

So: two UniformGrid rows, every key an equal share of the width, nothing scrollable, 40 tall. Every key
kept. Arrows on the lower row where the thumb rests, reordered to ← ↓ ↑ → so the pairs that undo each other
are neighbours. It costs about 51 pixels of terminal, four or five lines, and that is the right trade: the
row that was cheaper did not work.

The keys also gain a pressed state, which they had none of. They are Focusable="False" so that using one
does not take the keyboard off the terminal, and a button that never takes focus never shows the adorner
Fluent would otherwise give it — leaving no feedback at all on a control whose only job is to be pressed.
Their looks move from assignments in the code-behind to Button.hotkey, which is what lets a style say
:pressed, and the Ctrl latch becomes a class rather than two brushes written by hand.

── and five smaller ones ────────────────────────────────────────────────────────────────────────────────
The keyboard's inset was never cleared when the app was resumed without the keyboard it was applied for.
Android takes the keyboard away as the activity stops and Avalonia's input pane raises no StateChanged,
the pane going with the window rather than closing in front of one — so the interface came back holding a
whole keyboard's height of empty canvas. 838 of 2340 pixels on a Pixel 5, on every screen, until something
opened and closed the keyboard. MainActivity now raises PhoneEnvironment.Resumed and PhoneShell re-asks the
pane. It asks rather than assuming zero: a permission prompt or the biometric sheet can hand the activity
back with the keyboard genuinely still up, and flattening the inset there would strand the focused box
under a real one.

TextBlock.detail never wrapped, where .body beside it always has. A block that neither wraps nor trims lays
out at its full single-line width and the parent clips it, with no ellipsis to say anything is missing — so
the add sheet read "A machine to connect to, filed under a group if you" and stopped. Which of the fifty-odd
.detail blocks overflows is a function of width and font scale rather than of the string, so this is a style
rather than an attribute on the handful visibly wrong on one phone. The nine that genuinely want one line
now say NoWrap beside their TextTrimming, which is the pairing that was always meant.

The two port boxes are NumericUpDowns and were the only unthemed controls on this head — Fluent's border and
fill, next to a TextBox.field sharing their row. App.axaml has styled NumericUpDown for the desktop all
along; this head never had one.

Three buttons classed "icon accent" were painting Fluent's own Button.accent, #6275AC, a blue in no palette
here. The desktop overrides that style and this head did not, so the same class read correctly there and not
here.

The host key sheet said "First contact with 10.0.2.2 · 2222 . Nothing in this keychain…" — Avalonia puts a
space between adjacent Runs and the last one began with the full stop. A gap before a full stop, on the one
dialogue whose whole job is to be read carefully before it is answered.

── checks ──────────────────────────────────────────────────────────────────────────────────────────────
manual-checks gains 10.4a and 11.10f. 10.4 already covered dismissing the keyboard with back or the
chevron but not leaving the app with it up, which is the path the inset bug shipped through; 10.4a covers
both directions, since a fix that flattened the inset on every resume would pass one half and fail the
other. 11.10f guards the keypad against a ScrollViewer being put back around it.

src/DodoSSH.Client.Android/Theme/Phone.axaml

@@ -167,10 +167,124 @@
     <Setter Property="Foreground" Value="{StaticResource AccentText}" />
     <Setter Property="FontSize" Value="20" />
   </Style>
+  <!--
+    ◆ THE FILL BELOW IS NOT DECORATION. IT IS UNDOING ONE FLUENT PUTS THERE.
+
+    `accent` is not a name this theme invented — Fluent ships a `Button.accent` style of its own, and a
+    button classed `icon accent` matches it. So these three buttons were being painted with Fluent's
+    system-accent slab, #6275AC, a blue that appears nowhere in Palette.axaml and reads as a control from
+    a different application sitting in this one's header. Measured off a screenshot rather than guessed:
+    the fill was #6275AC where the accent is #5D42DE.
+
+    The rule above could not stop it, because it sets Foreground and FontSize and Fluent's fill is on the
+    ContentPresenter — which is also why `Button.icon`'s own Background="Transparent" does not reach it.
+    App.axaml has carried the desktop's answer to exactly this since v5b: override the ContentPresenter,
+    not the Button. This head simply never had one, so the desktop looked right and the phone did not.
+
+    Transparent rather than the desktop's gradient, and the difference is the control rather than an
+    inconsistency. The desktop's Button.accent is a filled primary slab — this head has one of those too,
+    and it is Button.primary. `icon accent` is a 44-pixel glyph in a header row beside other glyphs; what
+    "accent" asks for there is the accent *colour on the mark*, which is what the rule above gives it. A
+    slab would make one header icon a button and its neighbours not.
+
+    Pressed is deliberately not restated: Button.icon:pressed below sets ChromeHover on every icon button
+    and, coming later in this file, wins over this rule for the moment a finger is down. That is the
+    feedback the plain icon buttons give and there is no reason this one should differ.
+  -->
+  <Style Selector="Button.icon.accent /template/ ContentPresenter#PART_ContentPresenter">
+    <Setter Property="Background" Value="Transparent" />
+    <Setter Property="BorderThickness" Value="0" />
+    <Setter Property="Foreground" Value="{StaticResource AccentText}" />
+  </Style>
+  <Style Selector="Button.icon.accent:pointerover /template/ ContentPresenter#PART_ContentPresenter">
+    <Setter Property="Background" Value="Transparent" />
+    <Setter Property="Foreground" Value="{StaticResource AccentText}" />
+  </Style>
+  <Style Selector="Button.icon.accent:disabled /template/ ContentPresenter#PART_ContentPresenter">
+    <Setter Property="Background" Value="Transparent" />
+    <Setter Property="Foreground" Value="{StaticResource TextFaint}" />
+  </Style>
   <Style Selector="Button.icon:pressed /template/ ContentPresenter">
     <Setter Property="Background" Value="{StaticResource ChromeHover}" />
   </Style>
 
+  <!--
+    ============ one key of the terminal's accessory keypad ============
+
+    A class rather than eleven sets of attributes assigned in code, and the move out of the code-behind is
+    most of what makes the latched state honest: Ctrl on and Ctrl off used to be two Background values
+    written by hand in TerminalScreen.axaml.cs, which meant the row named two of this palette's brushes
+    itself and any third state would have named a third. It is `latched` here, and the code toggles a class.
+
+    ── the numbers, and why they are these ─────────────────────────────────────────────────────────────────
+    40 tall, where the row this replaced was 30. Android asks for 48 on a touch target and every terminal on
+    the platform lands near it; 30 was chosen to save a strip of the terminal above and took the keypad past
+    the point of working, which is the wrong end of that trade. 40 with a 2-pixel margin gives 44 of pitch,
+    which is the same figure TextBox.field uses for a box a thumb has to hit.
+
+    HorizontalAlignment Stretch, because these live in UniformGrid cells and the cell is the share of the
+    width the key is entitled to. Left to Center a key would shrink to its label and "|" would be a sliver
+    between two wide neighbours — which is the layout the flexed row exists to stop.
+
+    ── pressed has to be visible, and it was not ───────────────────────────────────────────────────────────
+    These keys are Focusable="False" so that using one does not take the keyboard away from the terminal
+    (see TerminalScreen.axaml.cs), and a button that never takes focus also never shows the focus adorner
+    Fluent would otherwise give it. That left a press with no feedback at all on a control whose entire job
+    is to be pressed while somebody is looking at the line of output above it. The pressed fill below is the
+    only thing that says a key was hit — and on a keypad over a remote shell, "did that send?" is a question
+    worth answering in the interface rather than in the scrollback.
+  -->
+  <Style Selector="Button.hotkey">
+    <Setter Property="Height" Value="40" />
+    <Setter Property="MinHeight" Value="40" />
+    <Setter Property="MinWidth" Value="0" />
+    <Setter Property="Margin" Value="2,0" />
+    <Setter Property="Padding" Value="0" />
+    <Setter Property="CornerRadius" Value="10" />
+    <Setter Property="Background" Value="{StaticResource Panel}" />
+    <Setter Property="BorderBrush" Value="{StaticResource BorderMid}" />
+    <Setter Property="BorderThickness" Value="1" />
+    <Setter Property="Foreground" Value="{StaticResource TextDim}" />
+    <Setter Property="FontFamily" Value="{StaticResource MonoFont}" />
+    <Setter Property="FontSize" Value="12" />
+    <Setter Property="HorizontalAlignment" Value="Stretch" />
+    <Setter Property="VerticalAlignment" Value="Center" />
+    <Setter Property="HorizontalContentAlignment" Value="Center" />
+    <Setter Property="VerticalContentAlignment" Value="Center" />
+  </Style>
+  <Style Selector="Button.hotkey /template/ ContentPresenter#PART_ContentPresenter">
+    <Setter Property="Background" Value="{StaticResource Panel}" />
+    <Setter Property="BorderBrush" Value="{StaticResource BorderMid}" />
+    <Setter Property="BorderThickness" Value="1" />
+    <Setter Property="CornerRadius" Value="10" />
+  </Style>
+  <Style Selector="Button.hotkey:pointerover /template/ ContentPresenter#PART_ContentPresenter">
+    <Setter Property="Background" Value="{StaticResource Panel}" />
+    <Setter Property="BorderBrush" Value="{StaticResource BorderMid}" />
+  </Style>
+  <Style Selector="Button.hotkey:pressed /template/ ContentPresenter#PART_ContentPresenter">
+    <Setter Property="Background" Value="{StaticResource Active}" />
+    <Setter Property="BorderBrush" Value="{StaticResource Accent}" />
+  </Style>
+  <!--
+    Latched Ctrl. The same fill a press gives, held rather than flashed — a modifier that is on and does not
+    look on is how somebody sends ^L to a database prompt believing they typed an l.
+  -->
+  <Style Selector="Button.hotkey.latched">
+    <Setter Property="Foreground" Value="{StaticResource AccentText}" />
+  </Style>
+  <Style Selector="Button.hotkey.latched /template/ ContentPresenter#PART_ContentPresenter">
+    <Setter Property="Background" Value="{StaticResource Active}" />
+    <Setter Property="BorderBrush" Value="{StaticResource Accent}" />
+  </Style>
+  <Style Selector="Button.hotkey:disabled /template/ ContentPresenter#PART_ContentPresenter">
+    <Setter Property="Background" Value="{StaticResource Panel}" />
+    <Setter Property="BorderBrush" Value="{StaticResource Border}" />
+  </Style>
+  <Style Selector="Button.hotkey:disabled">
+    <Setter Property="Foreground" Value="{StaticResource TextFaint}" />
+  </Style>
+
   <!--
     The floating action button the design has asked for since v2, and which this theme refused twice — on
     the grounds that it would open an editor this head had not got, and that an unused style is a claim the
@@ -398,6 +512,58 @@
     <Setter Property="FontSize" Value="12" />
   </Style>
 
+  <!--
+    ◆ The two port boxes, which are NumericUpDowns and were the only unthemed controls on this head.
+
+    They sit in a two-column Grid with a plain TextBox.field beside them — port next to username in the host
+    editor, and port next to default-user in the group editor — so the mismatch was not subtle: a bright
+    Fluent border and a near-black fill against this theme's #101019 and hairline, at the one place on the
+    screen where the two are a hand's width apart and directly comparable.
+
+    Not `Classes="field"` on the two call sites, because that class is a TextBox class and this is not a
+    TextBox: NumericUpDown is a ButtonSpinner wrapping one, so half the chrome being corrected belongs to
+    the spinner and would not take a TextBox setter. Typing the control instead also means a third port box
+    added later is right without anybody remembering, which is the property the desktop's own bare
+    `Selector="NumericUpDown"` in App.axaml has had since it was written.
+
+    Three selectors rather than one for the same reason Button.icon.accent needs two: Fluent puts the fill
+    and the border on template parts, and a value set on the control alone is a TemplateBinding the theme's
+    own wins over. The numbers are TextBox.field's, exactly — 44 tall, 10 radius, Field on BorderMid — so
+    the pair reads as one row of two boxes rather than as a box and a visitor.
+  -->
+  <Style Selector="NumericUpDown">
+    <Setter Property="Height" Value="44" />
+    <Setter Property="MinHeight" Value="44" />
+    <Setter Property="VerticalContentAlignment" Value="Center" />
+    <Setter Property="Background" Value="{StaticResource Field}" />
+    <Setter Property="BorderBrush" Value="{StaticResource BorderMid}" />
+    <Setter Property="BorderThickness" Value="1" />
+    <Setter Property="CornerRadius" Value="10" />
+    <Setter Property="Foreground" Value="{StaticResource Text}" />
+    <Setter Property="FontFamily" Value="{StaticResource MonoFont}" />
+    <Setter Property="FontSize" Value="12" />
+  </Style>
+  <Style Selector="NumericUpDown /template/ ButtonSpinner">
+    <Setter Property="Background" Value="{StaticResource Field}" />
+    <Setter Property="BorderBrush" Value="{StaticResource BorderMid}" />
+    <Setter Property="BorderThickness" Value="1" />
+    <Setter Property="CornerRadius" Value="10" />
+    <Setter Property="MinHeight" Value="44" />
+  </Style>
+  <!--
+    The inner box gives its chrome up entirely: the spinner above is drawing the border and the fill, and a
+    TextBox that kept its own would put a second rounded rectangle a pixel inside the first.
+  -->
+  <Style Selector="NumericUpDown /template/ TextBox">
+    <Setter Property="Background" Value="Transparent" />
+    <Setter Property="BorderThickness" Value="0" />
+    <Setter Property="Padding" Value="14,0" />
+    <Setter Property="VerticalContentAlignment" Value="Center" />
+    <Setter Property="Foreground" Value="{StaticResource Text}" />
+    <Setter Property="FontFamily" Value="{StaticResource MonoFont}" />
+    <Setter Property="FontSize" Value="12" />
+  </Style>
+
   <!--
     Every box on this head that takes a secret, and it is a class rather than two attributes repeated five
     times because the two attributes are not interchangeable and both are needed.
@@ -473,10 +639,29 @@
     <Setter Property="FontSize" Value="9.5" />
     <Setter Property="FontWeight" Value="SemiBold" />
   </Style>
+  <!--
+    ◆ Wraps, like .body below it, and the omission was doing real damage rather than none.
+
+    A TextBlock that neither wraps nor trims does not shrink to fit and does not report that it did not:
+    it lays out at its full single-line width and the parent clips whatever runs past the edge. So a
+    .detail long enough to overflow ended mid-word against the screen, with no ellipsis to say anything
+    was missing — "A machine to connect to, filed under a group if you" on the add sheet, which reads as
+    a sentence somebody forgot to finish rather than as text that was cut.
+
+    It is a style rather than an attribute on the ones that overflow today, because which of the fifty-odd
+    .detail blocks overflows is a function of the device's width and the user's font scale, not of the
+    string: every one of them is a candidate at 320dp that is fine at 411dp, and fixing the handful that
+    happen to be visibly wrong on a Pixel 5 would leave the rest to be found one narrow phone at a time.
+
+    The nine that genuinely want one line — list rows and log lines, where a wrapped detail would push the
+    row's own height around — now say TextWrapping="NoWrap" beside their TextTrimming, which is the pairing
+    that was always meant and was previously being had by accident.
+  -->
   <Style Selector="TextBlock.detail">
     <Setter Property="FontFamily" Value="{StaticResource MonoFont}" />
     <Setter Property="Foreground" Value="{StaticResource TextFaint}" />
     <Setter Property="FontSize" Value="10" />
+    <Setter Property="TextWrapping" Value="Wrap" />
   </Style>
   <Style Selector="TextBlock.body">
     <Setter Property="FontFamily" Value="{StaticResource MonoFont}" />