Merge main into the phone connections branch

Main had already taken this branch's first two commits, so what merged is the
Connections work against three things that landed beside it. Four of the six
conflicts were prose about arrangements both sides changed; two were real.

**The phone hub gained a Teams row while this branch was moving the keychain
onto it.** Both are additions to `IsMoreSurface` and both belong: teams because
the desktop reaches them from its rail and the phone through the hub, the
keychain because a bottom bar is for the places a session moves between. The
membership test, the back gesture's first case and the hub's own arithmetic all
take the union. The distinction is now written down rather than implied — teams
is the design's count plus one, and the keychain is the only rearrangement of
it: the bar lost a slot to gain that row.

**`ConnectAndAnnounceAsync` was the real one.** Main gave it
`RememberTypedPasswordAsync`, which binds the password that just worked to the
host it worked on; this branch had replaced the `HostRowViewModel` that method
needs with a four-field `ConnectionTarget`. Keeping both meant deciding what a
manual connection does with a password that succeeded, and the answer was
already written on the screen it is typed into: nothing. There is no item to
bind a credential to and none to bind it on, and that path saves nothing by
design.

So `ConnectionTarget` carries the row again — as a nullable, in place of the
host id it had, with `HostId` derived from it. Two things read it and both are
things that can only be done to a keychain item rather than to an address:
naming the log entry, and keeping the password. Null is not missing data there;
it is the whole of what makes the manual path different, and having one field
rather than two keeps "was this a keychain host" a question with one answer.

The desktop's rail lost SFTP and S3 to the tab strip on main, so the README's
"a rail with nine slots has room" was true when it was written this afternoon
and is not now. It says the room rather than the number.

Phase 11's four new device checks and main's Phase 12 on teams were the same
conflict twice — two appends to the end of one file — and both are kept.

Verified after resolving: the solution builds, the Android head builds clean,
and 837 tests pass across the seven client suites, including main's own additions
(233 shell, 79 layout, 240 domain, 118 sync, 54 session, 74 terminal, 39
storage).

src/DodoSSH.Client.Android/Views/PhoneShell.axaml

@@ -14,10 +14,11 @@
     state machine. What differs is only what each one draws.
 
     ── v2 ────────────────────────────────────────────────────────────────────────────────────────────────
-    The desktop's eight rail destinations become four in a bottom bar, and five more live one tap deeper
-    behind MORE: snippets, SFTP, S3, logs and preferences. That is the v2 design's own arrangement, and it
-    replaces the first design's four, which had nothing behind them at all. Five characters was a desktop
-    constraint and the phone uses words.
+    The desktop's eight rail destinations become four in a bottom bar, and the rest live one tap deeper
+    behind MORE: snippets, SFTP, S3, logs, preferences — and teams, which v2 did not draw and which is
+    argued for on the screen itself. That is the v2 design's own arrangement, and it replaces the first
+    design's four, which had nothing behind them at all. Five characters was a desktop constraint and the
+    phone uses words.
 
     The order is the design's rather than the rail's. Terminal sits second, beside Hosts, because those two
     are the pair a session moves between; on the desktop the terminal is not a rail entry at all.
@@ -58,7 +59,7 @@
 
         Hidden behind SETTINGS, and that is the design's arrangement rather than a saving. v2 gives every
         screen one header carrying that screen's own name and its own actions — a back arrow, an add, a
-        refresh — so the hub screens draw their own and this one stands down rather than stacking a second
+        refresh — so the hub's screens draw their own and this one stands down rather than stacking a second
         row of chrome above theirs. What is left is HOSTS, which is the screen the application opens on and
         the one where the vault's name and the sync light are the most useful thing a header could say.
 
@@ -135,7 +136,7 @@
           ============ under MORE ============
 
           The hub itself takes the shell as its data context, because every row on it is a navigation
-          command; the five destinations behind it each take the view model they are about, so each one is
+          command; the destinations behind it each take the view model they are about, so each one is
           wrapped. SnippetsScreen and LogsScreen are nullable on the shell — they are rebuilt on every
           unlock and nulled on lock — and it is the collapsed wrapper that keeps a template from binding
           against nothing.
@@ -150,6 +151,15 @@
           <views:LogsScreen DataContext="{Binding LogsScreen}" />
         </Panel>
 
+        <!--
+          The sixth destination behind MORE, and the one v2 never drew — see the comment on the screen
+          itself. Wrapped like its neighbours even though Teams is not nullable: the reason for the wrapper
+          is the data context, not the null. IsTeamShowing is the shell's and Teams is not the shell.
+        -->
+        <Panel IsVisible="{Binding IsTeamShowing}">
+          <views:TeamsScreen DataContext="{Binding Teams}" />
+        </Panel>
+
         <!--
           One screen for both file destinations. SFTP and S3 differ in which picker they offer and in
           nothing else below it — the panes, the queue and the transfers are the same IRemoteFileStore
@@ -282,13 +292,14 @@
                            Command="{Binding ShowTerminalCommand}" />
 
           <!--
-            IsMoreSurface rather than IsMoreShowing: this tab stands for seven screens, and a bar that went
-            dark the moment you opened one of them would only ever light two of its three entries.
+            IsMoreSurface rather than IsMoreShowing: this tab stands for the hub and everything behind it,
+            and a bar that went dark the moment you opened one of them would only ever light two of its
+            three entries.
 
-            "Settings" and a gear, where it was "More" and a hamburger. The hub held five destinations and a
-            paragraph and could not be called anything better than More; with the keychain and preferences
-            both on it, it is the place everything that is not connecting to something lives — which is what
-            a gear has meant on a phone since before this application existed.
+            "Settings" and a gear, where it was "More" and a hamburger. The hub held a handful of things
+            that did not fit and could not be called anything better than More; with the keychain, teams and
+            preferences all on it, it is the place everything that is not connecting to something lives —
+            which is what a gear has meant on a phone since before this application existed.
           -->
           <views:NavButton Grid.Column="2" Label="Settings" Glyph="⚙" IsCurrent="{Binding IsMoreSurface}"
                            Command="{Binding ShowScreenCommand}"