Take the group's EDIT and DELETE off the heading row

A pair of buttons sat at the end of the GROUPS heading, and the card's own
right-click menu arrived later offering the same two things. Two controls for one
job, and the buttons were the harder of the two to read: a button beside a
heading has no card under a pointer to mean, so it had to work its subject out —
the selected card, or failing that the group the trail ends with, which once a
group is open is not a card on screen at all. The menu never has that problem,
because opening it is what aims it.

The menu is the whole of Edit and Delete on the desktop now. ShowsGroupActions
went with the buttons, since hiding them was all it did. GroupTarget stays: the
menu's two entries read it after the code-behind has selected whatever was
right-clicked, and its fallback to the open group is what makes + NEW HOST open
on the group somebody is standing in rather than on none.

One case changes shape. Opening a group with nothing inside it folds the card
grid away, so from in there nothing can be right-clicked — renaming that group
means pressing the trail back one level, to where it has a card of its own. The
buttons used to cover it through the fallback. The trail was already the way out
of an empty group, and 3.2a says so now.

The test that pressed EDIT through its binding is replaced by one holding that
no button on the screen commands either of them, which is the failure worth
catching: a button coming back is not a compile error, and it would draw itself
in place, aimed at the group the trail ends with. What that test covered — a
command that has to accept an empty parameter, and act on the card the pointer
was on — the two menu tests beside it already do.

src/DodoSSH.Client.Shell/ViewModels/VaultViewModel.cs

@@ -1466,7 +1466,7 @@ internal sealed partial class VaultViewModel(
     /// </para>
     /// <para>
     /// <b>Separate from <see cref="SelectedGroup"/>, and no longer sets it.</b> The two answer different
-    /// questions — "what is on screen" and "what would EDIT and DELETE act on" — and while one click meant
+    /// questions — "what is on screen" and "which card is chosen" — and while one click meant
     /// both there was no way to name a group without also narrowing the grid to it. Two gestures, two
     /// properties; <see cref="GroupTarget"/> is where the two meet.
     /// </para>
@@ -2584,26 +2584,23 @@ internal sealed partial class VaultViewModel(
     internal bool IsConfirmingGroupDeletion => PendingDeletion?.Target is DeletionTarget.Group;
 
     /// <summary>
-    /// What the group panel's EDIT and DELETE act on: the card that is selected, or the group that is open.
+    /// What a group command with no argument acts on: the card that is selected, or the group that is open.
     /// </summary>
     /// <remarks>
-    /// Two answers, because a card is no longer where the user is. Selecting one aims the buttons at it,
-    /// which is what a click has always done; with nothing selected they aim at the group whose contents are
-    /// on screen — the one the trail ends with. Without that fallback a group with no groups inside it could
-    /// be opened and then never edited, because opening a group is exactly what takes its own card off the
-    /// screen. It is also what a file manager does: act on the selection, and on the current folder when
-    /// there is none.
+    /// Two answers, because a card is no longer where the user is. Selecting one aims at it, which is what a
+    /// click has always done; with nothing selected the answer is the group whose contents are on screen —
+    /// the one the trail ends with. That fallback is what makes + NEW HOST open on the group somebody is
+    /// standing in rather than on none, and it is what a file manager does: act on the selection, and on the
+    /// current folder when there is none.
+    /// <para>
+    /// The desktop's Edit and Delete reach this through the card menu, which selects whatever was
+    /// right-clicked first, so the fallback is not what they read — see <c>HostsScreen.OnGroupContextRequested</c>.
+    /// They used to be a pair of buttons beside the GROUPS heading, which had no card under a pointer to
+    /// mean and so leaned on it.
+    /// </para>
     /// </remarks>
     internal HostGroupRowViewModel? GroupTarget => SelectedGroup ?? GroupFilter;
 
-    /// <summary>Whether the group panel's buttons are showing.</summary>
-    /// <remarks>
-    /// Hidden with nothing to act on as well as while the question is up. A pair of buttons over a grid of
-    /// cards nobody has chosen between is a pair whose subject the user has to work out, and the answer
-    /// would be "neither" — see <see cref="GroupTarget"/>.
-    /// </remarks>
-    internal bool ShowsGroupActions => GroupTarget is not null && !IsConfirmingGroupDeletion;
-
     /// <summary>Whether this vault has any groups, which is what makes the sidebar draw headings.</summary>
     internal bool HasGroups => Groups.Count > 0;
 
@@ -4743,8 +4740,9 @@ internal sealed partial class VaultViewModel(
     /// <summary>Loads the group being acted on into the box, so saving renames it.</summary>
     /// <param name="group">
     /// The group to edit, or null for whatever the screen is aimed at — the selected card, or the open group
-    /// when no card is selected. See <see cref="GroupTarget"/>. The desktop's EDIT button passes nothing and
-    /// means the second; the phone has no card to select and passes the group its heading names.
+    /// when no card is selected. See <see cref="GroupTarget"/>. The desktop's card menu passes nothing and
+    /// means the card that was right-clicked, which opening the menu has already selected; the phone has no
+    /// card to select and passes the group its heading names.
     /// </param>
     /// <remarks>
     /// Taking it as an argument is what keeps the phone from having to select a group in order to edit one.
@@ -5110,7 +5108,7 @@ internal sealed partial class VaultViewModel(
     /// up under the ungrouped heading — so what the user needs to know is exactly how many machines are about
     /// to move, and that none of them are going anywhere else.
     /// <para>
-    /// Aims where EDIT does: at the selected card, or at the open group when no card is selected. See
+    /// Aims where Edit does: at the selected card, which on the desktop is the one the menu opened on. See
     /// <see cref="GroupTarget"/>.
     /// </para>
     /// </remarks>
@@ -8067,7 +8065,6 @@ internal sealed partial class VaultViewModel(
         DisarmIfAimedElsewhere(DeletionTarget.Group, GroupTarget?.EntityId);
 
         OnPropertyChanged(nameof(GroupTarget));
-        OnPropertyChanged(nameof(ShowsGroupActions));
     }
 
     /// <remarks>
@@ -8088,7 +8085,6 @@ internal sealed partial class VaultViewModel(
         DisarmIfAimedElsewhere(DeletionTarget.Group, GroupTarget?.EntityId);
 
         OnPropertyChanged(nameof(GroupTarget));
-        OnPropertyChanged(nameof(ShowsGroupActions));
 
         RebuildGroupLevel();
         RebuildVisibleHosts();
@@ -8101,7 +8097,6 @@ internal sealed partial class VaultViewModel(
         OnPropertyChanged(nameof(IsConfirmingGroupDeletion));
         OnPropertyChanged(nameof(ShowsHostActions));
         OnPropertyChanged(nameof(ShowsHostPaneActions));
-        OnPropertyChanged(nameof(ShowsGroupActions));
         OnPropertyChanged(nameof(ShowsItemActions));
     }