Tell the phone's keyboard these are secrets, and get it off the box

Five boxes on this head take a secret and every one of them was drawing dots
and saying nothing. `PasswordChar` is a screen property: Windows has no opinion
about what is being typed into a text box, so the desktop head needs nothing
more. Android's software keyboard has an opinion, and left at its default it
read a vault passphrase as prose — completions offered in the suggestion strip
above the box, and the passphrase itself learned into the IME's dictionary.
Dots on screen with a word bar over them is the worst of both: hidden from the
person typing it and offered to the room. `TextInputOptions.ContentType` is the
property the Android backend maps onto `InputType`, and it is what turns both
off. Both attributes now live in one `TextBox.secret` class rather than being
repeated per box, because they are two halves of one fact and the next box
added would have got one of them.

The keyboard also went on covering whichever box had raised it. That is in
`PhoneShell` rather than on each screen: everything the phone draws is inside
its one root panel, so a bottom margin shortens all eleven screens at once, and
a screen added later cannot forget to handle something it never had to know
about.

Two mechanisms, and it matters that neither is a backstop for the other. Before
Android 15 the activity now declares `AdjustResize` and the platform shortens
the window itself; left unspecified Android chooses, and what it chooses for a
window whose entire content is one native view — which is what an Avalonia
surface is — is to pan, sliding the window by however much it thinks the
focused native view needs and leaving the box exactly where it was. That was
the bug. From Android 15 the attribute is ignored, edge-to-edge being enforced
and the window no longer resized for the keyboard at all, and the reported
inset is what there is. Each is dead where the other applies — where the window
resizes, the inset arrives already consumed and measures zero — which is why
the margin comes from the inset alone. Both added together would strand the
interface an entire keyboard above the keyboard.

Scrolling the box back into view keys off the size change rather than off
either mechanism. `ScrollViewer` already brings a newly focused child into
view; what it cannot know is that the visible region shrank after the focus,
and both ways of losing that region end in the same resize.

None of it is reachable by a test. The software keyboard is an inset the
platform reports and a headless top level reports none, so phase 10 of
`docs/manual-checks.md` is the whole of the verification — including the note
to run it on one device each side of Android 15, since a build exercised on
only one of the two will look correct and be half broken.

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

@@ -320,6 +320,27 @@
     <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.
+
+    <b>PasswordChar is what the screen shows; ContentType is what the keyboard is told.</b> The desktop head
+    needs only the first — a Windows text box has no opinion about what is being typed into it. Android's
+    software keyboard does: left at its default it treats a passphrase box as ordinary prose, which means
+    the suggestion strip offers completions from everything that phone has ever been typed into, and the
+    IME's own learning dictionary remembers what was typed. Dots on screen and a word-suggestion bar above
+    them is the worst of both — the secret is hidden from the person typing it and offered to the room.
+    TextInputOptions.ContentType is the property the Android backend maps onto InputType, and Password is
+    what turns the suggestions off and keeps the entry out of the dictionary.
+
+    A field class is not implied. Two of the five boxes carry their own metrics — see LockedScreen — so this
+    one sets nothing about size or colour, and the other three say Classes="field secret".
+  -->
+  <Style Selector="TextBox.secret">
+    <Setter Property="PasswordChar" Value="•" />
+    <Setter Property="TextInputOptions.ContentType" Value="Password" />
+  </Style>
+
   <!--
     The live dot, and the class name is the same one the desktop sidebar uses so the two heads cannot
     drift on what green means: a terminal is open on this host right now. Deliberately not reachability —