Merge branch 'main' into the group's move and its deletion question

Main took the group's EDIT and DELETE off the GROUPS heading while this branch
was adding a MOVE beside them, so the conflict was about the same six pixels
from both directions. Main's answer wins outright, and it is the better one for
the reason its own message gives: a button beside a heading has no card under a
pointer to mean, and had to work its subject out from the selection or from the
trail. Moving a group had that problem worst of all — the thing it takes with it
is everything on the shelf, and "which shelf" is not a question a button there
could answer plainly.

So the MOVE button is gone and the menu entry it was drawn beside is the whole
of it. That entry was already in this branch, above the separator DELETE sits
below, and it needed no change: the card menu selects whatever was right-clicked
before it runs anything, which is exactly the aiming a group move wants.

Three things went with the button. ShowsGroupActions, which main deleted because
hiding buttons was all it did, and which this branch had extended to hide them
for the move panel as well. CanMoveGroupTarget, which existed to answer whether
that button was worth drawing — CanMoveSelectedHost stays, because the phone
really does leave the host's MOVE out rather than offer a refusal, and a menu
whose entries came and went would be a menu whose items move. And the two test
assertions that read them, which were describing the button rather than the
behaviour; what they were guarding is that the two panels never share the
moment, and IsConfirmingGroupDeletion says that directly.

The move panel and the deletion question both keep their place under the
heading, which is where the buttons were and is now simply where that section
puts things. They still exclude each other, by disarming rather than by a
visibility flag: MoveGroup clears a pending deletion and DeleteGroup folds the
move panel away.

Manual checks 3.3 was rewritten by main for the menu and by this branch for the
tick, and now says both; 3.3a is new and walks a two-level shelf across a vault
boundary, which is the half of this feature no headless test can watch land.

docs/manual-checks.md

@@ -324,7 +324,8 @@ phone's, whose list has no room for a row of group cards and draws the whole tre
 host filed, the grid says so in a sentence rather than sitting empty.
 
 **Then press a group card once.** It is marked as chosen and **nothing else happens** — the grid is still the
-level it was, and EDIT and DELETE now aim at that group. **Then double-press it.** The group opens: its hosts
+level it was, and no buttons appear beside the GROUPS heading: editing and deleting a group are on the card's
+own right-click menu, which is 7.9. **Then double-press it.** The group opens: its hosts
 are the grid, the trail above the cards reads `ALL HOSTS › <name> ›`, each card carrying the group's name as
 an accent chip, and the card grid shows what is *inside* that group rather than every group in the keychain.
 Pressing ALL HOSTS goes back to the outermost level.
@@ -347,9 +348,9 @@ Make two groups and file one under the other with the parent picker in the group
 
 **Pass:** only the outer group has a card to start with. Double-press it and the inner one is the only card
 shown, with the trail reading `ALL HOSTS › <outer> ›`. Double-press that, and the cards disappear entirely —
-it has nothing inside it — while the trail, EDIT and DELETE stay: with no card selected the two buttons act
-on the group the trail ends with, so a group with nothing in it can still be renamed after being opened.
-Pressing the **middle** crumb goes back one level rather than all the way out.
+it has nothing inside it — while the trail stays. Pressing the **middle** crumb goes back one level rather
+than all the way out, which is also how a group with nothing inside it is renamed: back out to the level
+where it has a card, and right-click that.
 
 **Failure means:** cards for groups that are not at this level is `VisibleGroups` having been bound past —
 the flat `Groups` is the phone's and the lookups'. A group that cannot be reached at all is worse and is the
@@ -370,13 +371,35 @@ takes only the group that is open.
 
 ### 3.3 Deleting a group with hosts in it
 
-Select a group with hosts and press DELETE.
+Right-click a group with hosts in it and choose **Delete…**. Do it twice: once leaving the tick alone, and
+once — on another group — ticking it.
 
-**Pass:** the question names how many hosts are filed under it and says they stay. Agreeing removes the
-group; the hosts lose their chip and are otherwise unchanged.
+**Pass:** the question names how many hosts are filed under it, says they stay and move to UNGROUPED, and
+offers a tick that would delete them as well. The tick starts clear, and it starts clear again on the next
+group even if it was set on the last one. Left clear, agreeing removes the group and the hosts stay, without
+a chip and otherwise unchanged. Ticked, the hosts go with it — and only the hosts that were filed under that
+group. A group with nothing under it is asked no second question and shows no tick.
 
-**Failure means:** if the hosts vanish, the delete is rewriting host payloads, which it must not — see
-`HostGroupRepository`.
+**Failure means:** a tick that carries from one question to the next is the reset in `OnPendingDeletionChanged`
+having gone, and it deletes machines on the strength of a decision about a different group. Hosts that keep
+the chip after an unticked delete are the unfiling not happening: they still name a group that is gone, which
+is what this used to do on purpose and no longer should.
+
+### 3.3a Moving a group to another vault · **needs a second vault**
+
+Build `outer › inner` with a host in `inner`, all in your personal vault, then right-click **outer** and
+choose **Move to another vault…**. Pick the shared vault and press MOVE.
+
+**Pass:** the panel says what travels and what does not before you press anything. Afterwards all three items
+carry the destination's badge, `inner` is still inside `outer` and the host is still inside `inner` — every
+one of them under an id it did not have a moment ago. The sentence names the vault, the counts, and the fact
+that the group now sits at the top level if it was nested. Nothing is left behind in the vault it came from.
+
+**Failure means:** a host under UNGROUPED in the destination is the group id having been carried across
+rather than remapped — the ids are the destination's making, so every reference has to be rewritten as its
+target lands. Anything still in the source vault is a partial move, which is survivable by design but should
+not happen with the network up: the groups are written top-down and the hosts last, so an interruption leaves
+hosts behind and never a shelf with nothing on it.
 
 ### 3.4 A group deleted on another machine · **needs two machines**
 
@@ -802,8 +825,9 @@ Delete.
 card, rather than back out to ALL HOSTS. Right-clicking the space around the group cards opens no menu.
 
 **Failure means:** the menu is reading `GroupTarget`'s fallback, which is the group whose contents are on
-screen. That fallback is right for the EDIT and DELETE buttons beside the heading and wrong for a menu that
-opened on a card.
+screen rather than the card the pointer is on. This menu is the only way to edit or delete a group on the
+desktop — there are no buttons beside the GROUPS heading any more — so a menu aimed wrongly is the whole of
+the mistake.
 
 ### 7.10 Clicking a host in the palette connects
 
@@ -1500,3 +1524,83 @@ delivery survives the failure because it is held against the transfer rather tha
 **Failure means:** a retry that succeeds but leaves the destination empty is the delivery having been
 dropped on the failure. An error saying the staged file is missing is the copy having been deleted at the
 stop, which is what `QueueDeliveredDownload` documents it does not do.
+
+## Phase 15 — Changes that arrive without a timer
+
+The socket is covered by tests on both sides: the endpoint suite opens a real one against a real
+`TestServer` and proves a push produces a notice, that another account's push does not, and that a frame
+carries no ciphertext; the shell suite proves a notice wakes the synchronisation loop long before the
+minute. What none of that can reach is **the network in between**, and that is where this feature is most
+likely to fail: a reverse proxy that will not upgrade, one that drops an idle socket without telling either
+end, a corporate middlebox, a phone moving between Wi-Fi and mobile data. Every one of those looks the same
+from inside a test host, which has no proxy and no radio.
+
+The pass condition throughout is *two* things, and the second matters as much as the first: it arrives
+quickly, **and** it still arrives when the socket is gone. A build where the timer had stopped working would
+pass every "it was fast" check here and fail nobody until somebody's proxy changed.
+
+### 15.1 A colleague's edit appears while you are looking at it
+
+Two accounts sharing a vault, both unlocked, both on the Hosts screen. On the first machine, rename a host
+in the shared vault and save.
+
+**Pass:** the second machine's list shows the new name within a second or two, with nothing pressed and no
+screen flicker — the row updates, the selection does not move, and the status line is not repainted with a
+sync report.
+
+**Failure means:** nothing within a minute, then the new name, is the socket not being established at all —
+that is the timer doing its job, which is the correct fallback and not the feature. Check `/api/v1/meta`
+lists `events`, then whether the proxy in front of the API forwards `Upgrade` and `Connection`. A list that
+never updates at all is a synchronisation failure and has nothing to do with this phase.
+
+### 15.2 A vault shared with you turns up as it is shared
+
+The second account signed in and unlocked, sitting on the VAULTS screen. From the first, add them to a team
+and press SHARE KEY.
+
+**Pass:** the vault appears in their list within a second or two of the key being wrapped, and reads as
+waiting for a key until the share, then as readable.
+
+**Failure means:** the vault appearing only on the minute is the `vaults.changed` notice not being published
+or not being followed. Both the membership add and the grant publish one; if the membership arrives promptly
+and the key does not, the grant path is the one to look at.
+
+### 15.3 It still works with the socket taken away
+
+On the second machine, block the WebSocket — the simplest way is a proxy rule rejecting the upgrade, or
+setting `Events:Enabled` to `false` on the server and restarting it.
+
+**Pass:** everything above still happens, within the minute rather than within seconds. Nothing on the
+screen says anything is wrong, because nothing is: no error, no OFFLINE badge, no repeated status message.
+The Sync button still works and still reports.
+
+**Failure means:** an error message, a titlebar claiming to be offline, or a status line that repaints with
+a socket failure is the client treating an absent push channel as a fault. It is not one — the timer is the
+guarantee and the socket is the optimisation, and a user with a strict proxy must never be told their
+keychain is broken.
+
+### 15.4 A laptop that slept comes back on its own
+
+With the second machine idle and connected, close the lid for a few minutes — or disable Wi-Fi for two
+minutes and re-enable it. Then make a change on the first machine.
+
+**Pass:** the change arrives quickly again, without the vault having been locked or the application
+restarted. The reconnection is invisible.
+
+**Failure means:** changes that arrive only on the timer from then on are the stream having given up after
+its socket died — the reconnection loop is what should make that impossible, and a client that reconnects
+once and not twice is the specific defect its tests exist to catch. Changes that never arrive again, timer
+included, are a different and worse bug in the synchronisation loop rather than in the socket.
+
+### 15.5 An expiring token does not end the push
+
+This one needs a short access-token lifetime in the identity provider — the dev realm's Keycloak client can
+be set to a couple of minutes. Leave a machine unlocked and idle for longer than that, then make a change
+elsewhere.
+
+**Pass:** the change still arrives quickly. The socket is closed by the server at the token's expiry and the
+client reconnects with a fresh one, which should be invisible.
+
+**Failure means:** notices stopping at roughly the token's lifetime is the reconnection not asking for a new
+token — it would be dialling with the spent one and being closed again immediately. A burst of reconnection
+attempts in the server log is the same defect seen from the other end.