Type a path on the SFTP pane, and put a file right without deleting it

Three things the file browser could not do. Somewhere to go had to be walked
to, a file that landed under the wrong name could only be removed and sent
again, and the listing went on showing the directory as it was before this
application put something in it.

◆ THE PATH IS A BOX NOW, not a TextBlock printing where the pane was. A
breadcrumb only reaches what is under the directory already listed, so crossing
a host's filesystem cost a click and a round trip a level, and a path somebody
already knew could not be entered at all. Enter goes; Escape puts back what the
pane is really showing.

What is typed may be absolute, relative to the directory showing, or start at
~ — the four shapes a shell takes, because somebody typing into a box is typing
what they would type into a shell. SftpPath.Resolve turns all of them into one
absolute path, and it resolves them here rather than handing a relative path to
the server: the server would resolve it against the session's own working
directory, which is not necessarily the directory the breadcrumb above the box
is showing. `..` is collapsed textually, which differs from cd through a
symbolic link; the alternative is a realpath round trip before anything lists.

The box holds its own value rather than RemotePath itself. Binding it straight
to the path would navigate on every keystroke — `/`, then `/v`, then `/va` — a
round trip and a failed listing per character. Every other way of moving writes
the real path back into it; a refused listing deliberately does not, because
the path that did not resolve is the one worth having in front of you.

◆ RENAME AND MOVE, and DELETE moves to join them. It had been sitting in the
pane header beside UP and REFRESH — two things that move the pane and one that
destroys a file, in one row — and the three that act on the selected row are
now together in a row of their own, under the name of the row they are about.

One SFTP rename underneath both new operations and two separate questions on
the screen, because the answer is a different kind of thing each time: a rename
takes a name and must not take a path, a move takes a directory and must not
take a name. One box asking for a destination path would be fewer controls and
a worse question — the two mistakes it invites are exactly the ones the split
makes impossible. Each form opens on the answer that changes nothing, so what
gets edited is the half somebody came to change.

Three refusals are made here, and they are the ones a server's message would
not explain: a separator in a name (no such file, about a directory nobody
meant to name), a destination equal to the source (success, and a file that did
not move), and a directory into itself (EINVAL, true and useless). Everything
else is the server's — a name already taken, a path that is not there, a mount
that cannot be crossed — and arrives in the status line in its own words.
Neither is painted in the deletion card's red: a rename is undone by renaming
back, and spending that red twice makes it stop meaning anything.

◆ THE LISTING REFRESHES ITSELF when a transfer lands in it. Both panes, since
an upload lands on the host and a download lands here and either leaves the
pane that is showing that directory a step behind. Only the directory actually
on screen: a queue moving a hundred files elsewhere must not be a round trip
per file for a listing nobody is looking at.

It waits rather than interrupting. Another operation running would have two
listings racing for one collection, and re-listing under an open question is
how the row somebody answered about stops being the row that gets acted on — so
the staleness is remembered and settled at the end of the operation or when the
question is dismissed. It says nothing either way: nobody asked for it, and the
status line at that moment is carrying the news about the transfer. The
selection survives, re-found by path, which is what makes an unasked-for
refresh safe to run under somebody's pointer at all.

◆ THE LAYOUT SUITE FOUND A REAL FAULT and the fix is where the height goes. The
rename form did not fit the 204 pixels the session shell's own sidebar leaves
this pane — MKDIR and the listing were pushed off the bottom. The form is
shorter now (the placeholder says what the box wants, so there is no field
label above it), and the item row and the breadcrumb step aside while any of
the three questions is up, which is what the phone head already did with its
own buttons.

Measuring also settled something the markup had been claiming and is not true:
at that width the listing collapses to nothing under any of the three cards,
the deletion card included, and has done since the sidebar arrived. So "the row
it is about is still on screen" is retired from the deletion card's remark, and
the full path each card carries is what identifies the row instead. Recorded
where it is drawn rather than left to be rediscovered.

TESTS. SftpPath.Resolve gets the four shapes, ~ with and without a home to
expand it to, a blank box, and climbing past the root. ShellFlowTests gets nine
against a session that records what it was asked to do — which path was
renamed, which directories were listed — rather than against the sentence this
code writes about itself: the path box absolute and relative, rename in place,
the separator refusal, a move by relative path, the no-op refusal, the three
questions displacing each other, and the three rules the automatic refresh
follows. The local half is in TransferQueueingTests, where a real folder
answers. Two new shapes are measured, and the deletion card's own measurement
moves to the connected state — the only state it can be asked in, and the
narrow one.

What the tests cannot reach is in docs/manual-checks.md as phase 2b: a real
server's cross-device and name-taken refusals, and a soft keyboard, which is
why the phone's path box has a GO button rather than trusting whatever the IME
decided to draw on its return key.

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

@@ -48,7 +48,7 @@
     the refusal has no continue button here either.
   -->
 
-  <Grid RowDefinitions="Auto,Auto,Auto,Auto,Auto,*,Auto">
+  <Grid RowDefinitions="Auto,Auto,Auto,Auto,Auto,Auto,*,Auto">
 
     <!-- ============ header ============ -->
     <Grid Grid.Row="0" ColumnDefinitions="Auto,Auto,*,Auto" Height="56" Margin="8,0">
@@ -174,8 +174,31 @@
       </StackPanel>
     </Border>
 
+    <!-- ============ ◆ typing where to go ============ -->
+    <!--
+      The breadcrumb below reaches only what is under the directory already listed, so crossing a host's
+      filesystem was a tap and a round trip a level and a path somebody already knew could not be entered at
+      all. This is the way in for one that is: absolute, relative to the directory showing, or starting at
+      ~. See SftpPath.Resolve.
+
+      GO is a real button rather than only the keyboard's own action key, and that is a phone decision: a
+      software keyboard's return key is whatever the IME decided to draw, this application does not set the
+      IME action, and a path box whose only commit was a key that may say "newline" would be a box nothing
+      could be submitted from. The Enter binding stays for the hardware keyboards this head does meet.
+    -->
+    <Grid Grid.Row="3" ColumnDefinitions="*,8,Auto" Margin="14,0,14,6" IsVisible="{Binding IsConnected}">
+      <TextBox Grid.Column="0" Classes="field" Text="{Binding RemotePathDraft}"
+               PlaceholderText="/path/to/somewhere">
+        <TextBox.KeyBindings>
+          <KeyBinding Gesture="Enter" Command="{Binding GoToTypedRemotePathCommand}" />
+        </TextBox.KeyBindings>
+      </TextBox>
+      <Button Grid.Column="2" Classes="secondary" Height="44" Padding="16,0" Content="GO"
+              Command="{Binding GoToTypedRemotePathCommand}" />
+    </Grid>
+
     <!-- ============ where we are ============ -->
-    <ScrollViewer Grid.Row="3" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Disabled"
+    <ScrollViewer Grid.Row="4" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Disabled"
                   IsVisible="{Binding IsConnected}" Margin="0,0,0,4">
       <StackPanel Orientation="Horizontal" Spacing="4" Margin="14,0" VerticalAlignment="Center">
         <Button Classes="row" MinHeight="36" Padding="9,0" CornerRadius="10"
@@ -215,7 +238,7 @@
       answers: an empty scrolling strip under the breadcrumb would read as a loading row rather than as
       "this host has nothing pinned".
     -->
-    <ScrollViewer Grid.Row="4" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Disabled"
+    <ScrollViewer Grid.Row="5" HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Disabled"
                   IsVisible="{Binding HasConnectedPins}" Margin="0,0,0,4">
       <ItemsControl ItemsSource="{Binding ConnectedPinnedPaths}">
         <ItemsControl.ItemsPanel>
@@ -240,7 +263,7 @@
     </ScrollViewer>
 
     <!-- ============ the listing ============ -->
-    <Panel Grid.Row="5">
+    <Panel Grid.Row="6">
 
       <TextBlock Classes="body" IsVisible="{Binding !IsConnected}" Margin="24,12"
                  VerticalAlignment="Top" Text="{Binding Status}" />
@@ -306,7 +329,7 @@
 
     <!-- ============ what to do with the chosen entry ============ -->
     <!-- DeepChrome rather than Chrome, since v5 — see the remark on PhoneShell's vault header. -->
-    <Border Grid.Row="6" IsVisible="{Binding IsConnected}" Background="{StaticResource DeepChrome}"
+    <Border Grid.Row="7" IsVisible="{Binding IsConnected}" Background="{StaticResource DeepChrome}"
             BorderBrush="{StaticResource Border}" BorderThickness="0,1,0,0" Padding="12,10">
       <StackPanel Spacing="9">
 
@@ -328,6 +351,36 @@
           </StackPanel>
         </Border>
 
+        <!--
+          ◆ Renaming and moving, in the place the deletion question already occupies and never at the same
+          time as it. One form for both — see RemoteMoveRequest for why the two questions share a shape and
+          differ only in their words — and no danger colours on it, because a rename is undone by renaming
+          back and the deletion above is the one thing here that nothing can walk back.
+        -->
+        <Border IsVisible="{Binding IsMovingRemote}" Background="{StaticResource Raised}"
+                BorderBrush="{StaticResource Border}" BorderThickness="1" CornerRadius="12"
+                Padding="13,11">
+          <StackPanel Spacing="6">
+            <TextBlock Classes="mono" FontSize="12" TextWrapping="Wrap"
+                       Text="{Binding PendingRemoteMove.Question}" />
+            <TextBlock Classes="detail" TextWrapping="Wrap" Text="{Binding PendingRemoteMove.FullPath}" />
+            <TextBox Classes="field" Text="{Binding RemoteMoveTarget}"
+                     PlaceholderText="{Binding PendingRemoteMove.FieldHint}">
+              <TextBox.KeyBindings>
+                <KeyBinding Gesture="Enter" Command="{Binding ConfirmMoveRemoteCommand}" />
+              </TextBox.KeyBindings>
+            </TextBox>
+            <TextBlock Classes="body" Text="{Binding PendingRemoteMove.Note}" />
+            <Grid ColumnDefinitions="*,8,*" Margin="0,4,0,0">
+              <Button Grid.Column="0" Classes="primary" Height="44"
+                      Content="{Binding PendingRemoteMove.ConfirmLabel}"
+                      Command="{Binding ConfirmMoveRemoteCommand}" IsEnabled="{Binding !IsBusy}" />
+              <Button Grid.Column="2" Classes="secondary" Height="44" Content="CANCEL"
+                      Command="{Binding CancelMoveRemoteCommand}" />
+            </Grid>
+          </StackPanel>
+        </Border>
+
         <!--
           ◆ The queue, above the actions and only when it has something in it. Bounded and scrolling rather
           than growing: five files queued must not push the buttons off the bottom of the screen, which on a
@@ -386,20 +439,32 @@
           save picker names one destination. CanDownload is the desktop's own flag for the same question —
           a file is selected and something is connected — and is reused rather than restated here.
         -->
-        <Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsConfirmingRemoteDeletion}">
+        <Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsAskingAboutRemoteEntry}">
           <Button Grid.Column="0" Classes="primary" Height="44" Content="ADD FILES" Click="OnAddFiles" />
           <Button Grid.Column="2" Classes="secondary" Height="44" Content="SAVE FILE" Click="OnSaveFile"
                   IsEnabled="{Binding CanDownload}" />
         </Grid>
 
-        <Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsConfirmingRemoteDeletion}">
+        <!--
+          ◆ The two that put a file right rather than taking it away, above the row DELETE is on and away
+          from it. Both open a form in place of these buttons — see the card above — because a phone has
+          nowhere to put a text field except where something else already was.
+        -->
+        <Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsAskingAboutRemoteEntry}">
+          <Button Grid.Column="0" Classes="secondary" Height="44" Content="RENAME"
+                  Command="{Binding RenameRemoteCommand}" IsEnabled="{Binding CanRenameRemote}" />
+          <Button Grid.Column="2" Classes="secondary" Height="44" Content="MOVE"
+                  Command="{Binding MoveRemoteCommand}" IsEnabled="{Binding CanMoveRemote}" />
+        </Grid>
+
+        <Grid ColumnDefinitions="*,8,*" IsVisible="{Binding !IsAskingAboutRemoteEntry}">
           <Button Grid.Column="0" Classes="secondary" Height="44" Content="DELETE"
                   Command="{Binding DeleteRemoteCommand}" IsEnabled="{Binding CanDeleteRemote}" />
           <Button Grid.Column="2" Classes="secondary" Height="44" Content="CLOSE"
                   Command="{Binding DisconnectCommand}" />
         </Grid>
 
-        <TextBlock Classes="body" IsVisible="{Binding !IsConfirmingRemoteDeletion}"
+        <TextBlock Classes="body" IsVisible="{Binding !IsAskingAboutRemoteEntry}"
                    Text="ADD FILES picks documents to send. SAVE FILE asks where the selected file should be kept — the file is created there when you choose it, so a transfer that fails leaves it empty." />
 
         <TextBlock Classes="detail" Foreground="{StaticResource TextDim}" TextWrapping="Wrap"