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/Views/TerminalScreen.axaml.cs

@@ -3,6 +3,7 @@ using System.Text;
 
 using Avalonia;
 using Avalonia.Controls;
+using Avalonia.Controls.Primitives;
 using Avalonia.Interactivity;
 using Avalonia.Layout;
 using Avalonia.Markup.Xaml;
@@ -39,7 +40,14 @@ internal sealed partial class TerminalScreen : UserControl
     /// keys to fit 360dp produces ten targets too small to hit.
     /// </para>
     /// </remarks>
-    private static readonly (string Label, byte[] Bytes, bool Latches)[] Keys =
+    /// <summary>The upper row: the modifiers, and the punctuation a symbols layer is two taps away from.</summary>
+    /// <remarks>
+    /// Seven, which is what the row divides between — see the keypad's remark in TerminalScreen.axaml for
+    /// why the set is fixed and flexed rather than scrollable. Adding an eighth is a matter of adding it
+    /// here and changing the <c>Columns</c> on the UniformGrid; the two numbers have to agree, and the row
+    /// simply gets narrower keys.
+    /// </remarks>
+    private static readonly (string Label, byte[] Bytes, bool Latches)[] ModifierKeys =
     [
         ("esc", [0x1B], false),
         ("tab", [0x09], false),
@@ -48,12 +56,31 @@ internal sealed partial class TerminalScreen : UserControl
         ("-", [(byte)'-'], false),
         ("~", [(byte)'~'], false),
         ("/", [(byte)'/'], false),
+    ];
 
-        // The cursor keys, as the ANSI sequences a PTY expects. Written out rather than composed, because
-        // the difference between CSI A and SS3 A is the difference between working in bash and not.
-        ("↑", [0x1B, (byte)'[', (byte)'A'], false),
-        ("↓", [0x1B, (byte)'[', (byte)'B'], false),
+    /// <summary>The lower row: the cursor keys, which is where they became reachable.</summary>
+    /// <remarks>
+    /// <para>
+    /// The ANSI sequences a PTY expects, written out rather than composed, because the difference between
+    /// CSI A and SS3 A is the difference between working in bash and not.
+    /// </para>
+    /// <para>
+    /// ◆ <b>Left, down, up, right</b> — the order every other client on the platform puts them in, and not
+    /// the order they were in here. On one flat row the pairs have to read as pairs: horizontal at the ends
+    /// and vertical in the middle means the two keys that undo each other are always neighbours, and a
+    /// thumb learns the row's shape rather than its labels. Up-down-left-right is the order they are named
+    /// in, which is a different thing from the order they are used in.
+    /// </para>
+    /// <para>
+    /// These four were the keys that used to live past the right-hand edge of the scroller — the most
+    /// pressed keys on the keypad, and the ones you had to go looking for.
+    /// </para>
+    /// </remarks>
+    private static readonly (string Label, byte[] Bytes, bool Latches)[] CursorKeys =
+    [
         ("←", [0x1B, (byte)'[', (byte)'D'], false),
+        ("↓", [0x1B, (byte)'[', (byte)'B'], false),
+        ("↑", [0x1B, (byte)'[', (byte)'A'], false),
         ("→", [0x1B, (byte)'[', (byte)'C'], false),
     ];
 
@@ -232,8 +259,6 @@ internal sealed partial class TerminalScreen : UserControl
 
     private void BuildAccessoryRow()
     {
-        var row = this.FindControl<StackPanel>("AccessoryKeys")!;
-
         // ── nothing to hand back any more ──────────────────────────────────────────────────────────────
         // This row used to counter both halves of every press with a posted TerminalFocus.Return(), because
         // the platform requests Android's own focus for Avalonia's view after dispatching each handled
@@ -242,7 +267,18 @@ internal sealed partial class TerminalScreen : UserControl
         // the keyboard already wants, and the counter-move is not merely unnecessary but wrong. The keys
         // stay Focusable=false, which is now what keeps Avalonia's own focus on the input surface.
 
-        foreach (var (label, bytes, latches) in Keys)
+        Fill(this.FindControl<UniformGrid>("AccessoryKeys")!, ModifierKeys);
+        Fill(this.FindControl<UniformGrid>("ArrowKeys")!, CursorKeys);
+    }
+
+    /// <summary>Puts one table's worth of keys into one row of the keypad.</summary>
+    /// <remarks>
+    /// The rows differ in what they hold and in nothing else — same control, same class, same wiring — so
+    /// they are filled by one method rather than by two that would drift.
+    /// </remarks>
+    private void Fill(UniformGrid row, (string Label, byte[] Bytes, bool Latches)[] keys)
+    {
+        foreach (var (label, bytes, latches) in keys)
         {
             var key = CreateKey(label);
 
@@ -265,29 +301,17 @@ internal sealed partial class TerminalScreen : UserControl
     private static Button CreateKey(string label) =>
         new()
         {
-            Content = new TextBlock
-            {
-                Text = label,
-                FontFamily = (FontFamily)Application.Current!.FindResource("MonoFont")!,
-                FontSize = 11,
-                HorizontalAlignment = HorizontalAlignment.Center,
-                VerticalAlignment = VerticalAlignment.Center,
-            },
+            Content = label,
 
-            // 44 wide, and that is the number that matters: the design draws these flexed across the
-            // width, which at 360dp with ten keys is 32 pixels each — under every thumb-target
-            // guideline there is. The height came down with the row it sits in, from 38 to 30, and it
-            // costs nothing a width does: the keys are a single row with the terminal above and the
-            // system's gesture bar below, so there is no neighbour a short press can land on instead.
-            MinWidth = 44,
-            Height = 30,
-            Padding = new Thickness(10, 0),
-            CornerRadius = new CornerRadius(9),
-            Background = Palette("Panel"),
-            BorderBrush = Palette("BorderMid"),
-            BorderThickness = new Thickness(1),
-            Foreground = Palette("TextDim"),
-            HorizontalContentAlignment = HorizontalAlignment.Center,
+            // ◆ Every dimension and brush this used to set by hand is now Button.hotkey in Phone.axaml,
+            // and the move is what lets the row have a pressed state at all: a style can say :pressed and
+            // an assignment cannot. It also takes this file out of the business of naming the palette's
+            // brushes, which is how a keypad ends up with a grey nothing else uses.
+            //
+            // Content is the string rather than a TextBlock built here for the same reason — the class
+            // carries the font and the alignment, so a wrapper element would only be somewhere for them to
+            // disagree.
+            Classes = { "hotkey" },
 
             // ◆ NOT FOCUSABLE, AND THAT IS THE WHOLE CONTROL RATHER THAN A DETAIL.
             //
@@ -316,18 +340,12 @@ internal sealed partial class TerminalScreen : UserControl
 
         // Latched state has to be visible. A modifier that is on and does not look on is how somebody sends
         // ^L to a database prompt believing they typed an l.
-        controlKey.Background = Palette(controlLatched ? "Active" : "Panel");
-        controlKey.Foreground = Palette(controlLatched ? "AccentText" : "TextDim");
+        //
+        // A class rather than two brush assignments, so what "latched" looks like is stated once in
+        // Phone.axaml beside what "pressed" looks like — which is where somebody changing either will be.
+        controlKey.Classes.Set("latched", controlLatched);
     }
 
-    /// <summary>One brush from <c>Theme/Palette.axaml</c>, by key.</summary>
-    /// <remarks>
-    /// The accessory row is built in code because its keys come from a table, so its colours cannot be set in
-    /// XAML with the rest of the screen's. Resolving them by name is the next best thing: a row that named
-    /// its own blues is how the palette ends up with a fifth surface nobody meant to add.
-    /// </remarks>
-    private static IBrush? Palette(string key) => Application.Current?.FindResource(key) as IBrush;
-
     /// <remarks>
     /// The control translation is the ASCII one and nothing cleverer: Ctrl-A through Ctrl-Z are 0x01 to
     /// 0x1A, which is letter &amp; 0x1F. Applied only to letters, because Ctrl with an arrow key is a