Move files to and from a host over SFTP

M2's file transfer, built bottom-up: an SFTP session on the SSH layer, a
transfer queue in a project of its own, and the two-pane browser the design
asked for replacing the screen that said it did not exist. Remote listings
carry names, sizes, modification times and a real drwxr-xr-x — nothing in this
repository could render a POSIX mode before — and the queue moves one file at a
time with progress, throughput and resume.

The design import assumed this would be an SFTP subsystem channel on
ISshConnection, beside the shell on a transport that is already up. SSH.NET
does not offer that: SftpClient derives from BaseClient and owns its own
transport, and there is no supported way to hand it an SshClient's session. So
file transfer opens a second authenticated connection, and it is named for
that rather than dressed up as a channel — OpenSftpAsync is on
ISftpSessionFactory, not on a connection. The difference is visible to a user:
the host records a second login, and a host whose password is typed each time
asks for it again on this screen. It goes through the same host key gate, the
same pin and the same two refusals a shell does, so a fingerprint approved for
a terminal is approved here and one approved here reaches the other machines
with the next sync. docs/design-import-gaps.md is corrected, and marked as the
one row where what shipped differs from what it predicted.

Nothing is written at its final name until it is complete. Every transfer goes
to a .dodossh-part file beside its destination and is renamed into place at the
end, so an interrupted transfer can never be mistaken for a finished one —
which matters most for what this screen is actually for, which is copying a
build artefact onto a server and then running it. A destination that already
exists is refused outright rather than overwritten: the queue has no way to
ask, and silently replacing a file somebody's process is serving is the worse
of the two failures. The remote pane has DELETE and MKDIR so that refusal is
not a dead end. A test against the container pins the assumption underneath all
of this — that SFTP's rename does not clobber.

Resume works within a run of the application and not across a restart, and the
limit is deliberate rather than unfinished. Nothing records which source wrote
a part file, and resuming one on the strength of its name matching is how a
corrupt artefact gets delivered with nothing reporting a failure; a part file
found at startup is started over. Making it survive a restart needs the
preferences store this client still has not got. The offset a resume starts at
is the part file's own length rather than the transfer's recorded progress: a
cancellation can land between a write completing and the counter moving, and
only one of those two is a fact about the bytes that are there.

The queue and its connection outlive a lock, as shells do. LockAsync already
argues that locking must not destroy work in flight — it is what somebody does
when they walk away from the machine, which is exactly when a long transfer is
most likely to be running — so TransfersViewModel is created once and the vault
is attached on unlock and detached on lock. What locking takes is the host
list, and it has to: those rows carry decrypted secrets.

DodoSSH.Client.Transfer is a new project rather than more of Client.Ssh. The
two answer different questions — one is about reaching a host, the other about
moving bytes and what to do when moving them stops halfway — and this is the
only client project that deliberately touches the local filesystem.

Three defects the tests found, none of which review would have. SftpPath.Name
answered an empty string for the root. NavigateRemoteAsync wrapped itself in
the busy guard, so navigating from inside another command did nothing at all
and the remote pane simply stayed empty after connecting, with no failure
anywhere to explain it. And opening an SFTP session per test made two
handshakes per test — this client learns a host key by being refused — which
pushed the SSH assembly past sshd's MaxStartups and failed a different few
unrelated tests each run; the session is shared through the fixture now, with
the reason written where the next person will hit it.

1004 tests green across 18 projects, 24 of them new: the SFTP subsystem against
the OpenSSH container, the queue against a real temporary directory and a fake
host, and three more layout measurements because a screen this window has never
laid out is a screen never checked.

Not verified: the screen has not been looked at running. The layout harness
measures it at the window's minimum in three shapes, which is the class of
defect that has shipped here before, but reaching it in the application needs
the compose stack, the migrations, the API and a browser sign-in. What is still
absent — the status bar's transfer count, dragging between the panes,
transferring a directory, and sftp over a bastion — is in
docs/design-import-gaps.md.

tests/DodoSSH.Client.Ssh.Tests/SshServerFixture.cs

@@ -29,7 +29,10 @@ public sealed class SshServerFixture : IAsyncLifetime
 
     private const int SshPort = 2222;
 
+    private readonly SemaphoreSlim sftpGate = new(1, 1);
+
     private IContainer? container;
+    private ISftpSession? sftp;
 
     /// <summary>Host port the container's sshd is published on.</summary>
     public ushort Port => container!.GetMappedPublicPort(SshPort);
@@ -68,9 +71,69 @@ public sealed class SshServerFixture : IAsyncLifetime
         await container.StartAsync();
     }
 
+    /// <summary>
+    /// One file-transfer session, opened on first use and shared by every test that wants one.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// Shared rather than opened per test, and that is a limit of the server rather than an optimisation.
+    /// sshd's <c>MaxStartups</c> drops connections at random once enough are part-way through a handshake,
+    /// and this client's first contact with an unknown host is a connection deliberately <em>refused</em> at
+    /// the host key — so a suite that opened its own session per test made two handshakes per test and
+    /// pushed the whole assembly over the threshold. What that looks like is unrelated tests failing with
+    /// "the connection was closed by the remote host", a different few each run.
+    /// </para>
+    /// <para>
+    /// Safe to share because an SFTP session holds no per-test state: every test here works in a directory
+    /// named after itself. See <c>ISftpSession</c>, which is one channel and is used by one caller at a
+    /// time.
+    /// </para>
+    /// </remarks>
+    public async ValueTask<ISftpSession> SftpAsync(CancellationToken cancellationToken)
+    {
+        await sftpGate.WaitAsync(cancellationToken);
+
+        try
+        {
+            if (sftp is not null)
+            {
+                return sftp;
+            }
+
+            var knownHosts = new InMemoryKnownHostStore();
+            var factory = new SshNetConnectionFactory(knownHosts);
+
+            var request = new SshConnectionRequest(
+                Host, Port, Username, new SshPasswordCredential(Password));
+
+            try
+            {
+                // Learned by being refused, which is the only way this client learns a host key.
+                return sftp = await factory.OpenSftpAsync(request, cancellationToken);
+            }
+            catch (SshHostKeyUnknownException unknown)
+            {
+                await knownHosts.TrustAsync(unknown.Presentation, cancellationToken);
+            }
+
+            return sftp = await factory.OpenSftpAsync(request, cancellationToken);
+        }
+        finally
+        {
+            sftpGate.Release();
+        }
+    }
+
     /// <inheritdoc />
     public async ValueTask DisposeAsync()
     {
+        if (sftp is not null)
+        {
+            await sftp.DisposeAsync();
+        }
+
+        sftpGate.Dispose();
+
         if (container is not null)
         {
             await container.DisposeAsync();