Give the phone both pickers, and settle who signs the APK

The files screen could browse a remote and delete on it, and that was all: there
is no browsable local filesystem on Android for a second pane to show, so the
gesture the desktop is built around — choose on the left, press the arrow — has
nothing to stand on. What replaces it is the platform's own two pickers. ADD
FILES is ACTION_OPEN_DOCUMENT, so a document is pointed at wherever it lives and
goes to the directory showing; SAVE FILE is ACTION_CREATE_DOCUMENT for the
selected row.

Both stage through the application's cache, and that copy is a requirement
rather than a shortcut. android-port.md predicted a picked document would be a
third IRemoteFileStore beside SFTP and S3; it cannot be. FileTransferQueue seeks,
because an upload resumes from the byte the last attempt reached, and a
content:// URI has no path behind it, no length worth trusting, no promised seek
and no grant that survives the document being edited underneath it. Copying
first costs one class in the head and nothing at all in the shared layers, where
the alternative was every resume rule rewritten around a stream that cannot
rewind. The copy is deleted when the transfer completes, kept while it is stopped
so RESUME still has something to read, and swept at the next launch — which is
the one moment emptying that directory is provably safe, since nothing has
queued anything yet.

Coming out had a decision going in did not: when to ask where it goes. The save
picker is raised before the transfer, so the download runs into the same staging
directory and hands its bytes to a callback the head supplied, held against the
transfer id so a RETRY still lands where the person pointed. Asking afterwards
would put the picker minutes from the button that caused it and, on a phone,
usually while the application is backgrounded and Android will not show one at
all. The cost is that the picker creates its file when it is dismissed, so a
download that then fails leaves an empty one there; that is said on the screen,
in the README and in the manual checks rather than left to be discovered. A
delivery that fails keeps the staged bytes for the sweep instead of throwing away
the one copy of something just fetched over somebody's network.

The foreground service counts transfers now, which is the half of it that
matters most here: a shell survives backgrounding because somebody is looking at
it, and an upload has to survive precisely when nobody is. Queued counts as
active, so putting five files in and locking the phone moves five files. The
seam was built for this and wired to () => 0 because nothing could fill the
queue.

Alongside it, ADR 0010 answers the second question android-port.md left open,
and it had to be answered before the first release rather than at upload time: a
new Play app must use App Bundles and therefore Play App Signing, and an
installed app can only be updated by a package signed with the same key, so the
first release picks an identity for good. The project holds the key, offline and
never in CI — the workflow's package step now says so where somebody would break
it — and a DodoSSH deployment never serves the client, because a download link on
your own server hands the binary that holds the plaintext to the party the whole
threat model is about.

The README's M1 gap note was stale in both halves and is replaced by what is
actually true: credentials have an editor and a REMEMBER tick, and the device key
registers into the TPM under a CNG policy that makes the consent dialog a
condition of using it. What is left is the floor rather than a gap — no TPM, or
no Windows, means the passphrase on every launch.

tests/DodoSSH.Client.App.Tests/TransferQueueingTests.cs

@@ -217,6 +217,70 @@ public sealed class TransferQueueingTests : IDisposable
         Queued().ShouldHaveSingleItem();
     }
 
+    /// <remarks>
+    /// The phone's way in, and it has to obey the same rules as every other: a document chosen in the system
+    /// picker is copied into the cache and the copy is queued, which is an upload with one extra property —
+    /// that this application made the file and will delete it again. Everything about *what may be queued*
+    /// is the same, and this says so rather than leaving a second path free to drift.
+    /// </remarks>
+    [Fact]
+    public void StagedUploads_QueueUnderTheSameRulesAsAnyOther()
+    {
+        Connected();
+
+        var folder = Path.Combine(directory, "a-folder");
+        Directory.CreateDirectory(folder);
+
+        transfers.QueueStagedUploads([File("picked.txt"), folder]);
+
+        Queued().ShouldHaveSingleItem();
+        transfers.Status.ShouldContain("1 file");
+        transfers.Status.ShouldContain("1 folder was skipped");
+    }
+
+    /// <remarks>
+    /// <para>
+    /// The phone's way out. The delivery itself — copying the finished file into the document the save
+    /// picker made — needs a transfer that actually runs and a picker to have made something, so it is
+    /// checked by hand in <c>docs/manual-checks.md</c> phase 14. What is worth pinning here is the pair of
+    /// refusals in front of it, because both would otherwise be discovered as an empty file sitting in
+    /// somebody's Downloads: the picker creates the destination the moment it is dismissed, so anything
+    /// this method turns away after that point has already cost a visible artefact.
+    /// </para>
+    /// </remarks>
+    [Fact]
+    public void ADeliveredDownload_QueuesTheFileAndRefusesADirectory()
+    {
+        var delivered = 0;
+
+        Connected();
+
+        transfers.QueueDeliveredDownload(
+            RemoteFile("one.log"),
+            Path.Combine(directory, "staged", "one.log"),
+            _ =>
+            {
+                delivered++;
+                return Task.CompletedTask;
+            });
+
+        Queued().ShouldHaveSingleItem();
+        transfers.Status.ShouldContain("one.log");
+
+        // A directory has nothing to fetch, and the message is the same one every other path on this screen
+        // gives for the same mistake.
+        transfers.QueueDeliveredDownload(
+            RemoteDirectory("logs"),
+            Path.Combine(directory, "staged", "logs"),
+            _ => Task.CompletedTask);
+
+        Queued().Count.ShouldBe(1);
+        transfers.Status.ShouldContain("Only files");
+
+        // Nothing is delivered by queueing. The callback runs when the bytes are there and not before.
+        delivered.ShouldBe(0);
+    }
+
     /// <summary>The queue's rows, once the posts that create them have been let run.</summary>
     /// <remarks>
     /// <c>TransfersViewModel</c> adds a row from the transfer queue's own <c>Changed</c> event, which it