Give the keychain the DELETE its confirmation was already written for

The counted confirmation has been on this screen since the phone got its
screens, and nothing could raise it. PendingDeletion is armed by
DeleteSelectedItemCommand and its siblings, and the only Delete bindings
anywhere on this head were the files screen's remote delete and the snippets
one — so the card, and the header comment calling it structural, described a
question the phone could not ask. The button is what was missing rather than
anything behind it: the command, the counting and the wording were all already
shared with the desktop.

It sits in row 2 beside that confirmation rather than in a bar at the foot of
the screen, which is where HOSTS and FILES put what to do with the chosen thing.
ShowsItemActions is SelectedItemIsEditable and not-already-asking, so sharing
the row makes the question take the place of the button that asked it, and
DELETE cannot be pressed a second time underneath its own confirmation. A button
at the bottom and its question at the top would be one exchange drawn twice.

DELETE alone, without the EDIT the desktop's detail pane offers beside it,
because there is nothing on this head for EDIT to open. That is also why the
bar names the item rather than trusting the highlight: it is the only thing on
screen saying which row is about to go.

And the highlight had to be made to exist. HOSTS and FILES fill the selected
ContentPresenter, which works because their rows are bare Borders; a keychain
row is Border.card, and the card paints an opaque Sidebar over it. The selector
reaches the card itself instead, in the same Active the chosen host wears, so
the row a button now acts on looks different from the ones it does not.

The TAGS comment said renaming and deleting happened here. Half of that is true
as of this commit and the other half is not — a tag is still renamed on the
desktop, because no kind of item opens an editor on this screen.

The README's paragraph about what the phone is missing said there was no host
editor, which stopped being true when the floating + and both editors landed. It
now names what is actually absent: no local pane for file transfer, no keychain
editor, and no screen at all for pins, teams or import.

README.md

@@ -280,9 +280,13 @@ screen exactly the width it was designed against.
 File transfer **is** here now, in the shape scoped storage allows: one remote pane and the queue, over
 either an SFTP host or a bucket. There is no local pane, because there is no browsable local filesystem to
 put in one — moving a file *in* from the phone needs the system document picker and is the next piece of
-work rather than a thing the screen pretends to do. What is still absent is a host editor and a keychain
-item editor, so hosts and keys are created on the desktop and sync down; pins, teams and import have no
-phone screen either. Importing an `~/.ssh/config` has no meaning on a phone at all.
+work rather than a thing the screen pretends to do. Hosts and groups are made and corrected here now, from
+a floating + on the Hosts screen, and both editors are cards in the list's own row rather than dialogs, so
+the form never covers the thing it is about. The keychain has no editor of its own: SSH keys, passwords and
+buckets are created on the desktop and sync down, and the phone will delete one — behind the same counted
+confirmation — without offering to change it. The one item this head makes is a tag, from inside a host's
+editor where tagging is what you were doing anyway; renaming one is still a desktop job. Pins, teams and
+import have no phone screen either. Importing an `~/.ssh/config` has no meaning on a phone at all.
 
 **Port forwarding is not built anywhere**, and the phone's More screen says so in a paragraph rather than
 leaving a gap. The v2 design draws a whole screen for it; nothing in the SSH layer forwards anything, so