Keep an open editor's pickers in step with the vault

The host editor's four pickers were snapshots taken when it opened, and the
comment on EditorAuthenticationChoices said why: a picker whose contents move
under somebody halfway through a form is worse than a list a minute stale, and
only one editor could be open at a time anyway, so the only way to add a key was
to close this one. The second half of that stopped being true when
AHostEditorIsInTheWay was split from AVaultEditorIsInTheWay. The host editor is
the Hosts screen's business and the keychain's editors are the Vault screen's;
neither refuses the other now, which was the right split — it stopped three
quarters of a screen going inert over an editor the user was not looking at — but
it left the assumption those snapshots rested on false and nothing to notice.

So the ordinary way of using the feature was the broken one. Somebody starts
editing a host, finds there is no key to bind it to, goes to KEYS, makes one, and
comes back to a picker that does not have it — with the fix being to throw the
form away and start again. The same for a password, a tag, a group, and for a
whole vault made on the Teams screen because the host being typed belongs to the
team rather than to the person typing it: the vault they had just made for it was
the one place they could not file it.

RefreshOpenEditors refills whichever editor is open, and it hangs off ReloadAsync
rather than off the twenty-odd commands that write to the vault. That is the
choice worth stating, because it is what makes a sync count as well as a save: a
key pulled from another machine reaches the open editor by the same path a key
typed here does, and a place that wrote to the vault without refreshing the editor
would be a bug nobody would find for months.

What the old comment was protecting against is real, so every picker is put back
onto what it was already showing, by id, and not one typed field is touched. An
editor that reset its own bindings because a background sync landed would be a
worse bug than the stale list this fixes — it would rebind a host as a side effect
of somebody else's work. The placeholder entries go back too, which is the case
3.4 measures: a group deleted on another machine mid-edit still cannot unfile the
host when the form is saved. The group editor gets the same treatment for the same
reasons; it shares the drawer, and its default binding is lent to every host under
it.

The snippet editor's vault picker was the same copy of the same list and went
stale the same way. It watches TargetVaults rather than the reload, because that
screen has always been a wrapper over the vault's collections and has no reload of
its own to hang off — which is how it already follows Snippets.

The move panels are deliberately left alone. A vault arriving from a sync while
one is open still will not appear in it, but a move panel is opened by the act that
fills it and its picker resets its selection to the first entry on every rebuild,
so refreshing it would move a destination somebody had chosen. Same class of bug,
different answer, and not this change.

Five tests, and four of them were checked failing with the RefreshOpenEditors call
commented out: a key reaching the open host editor and binding when chosen, an
item arriving without moving a selection that was already made, a tag arriving as
an unworn chip, a key reaching the group editor, and a vault reaching the host and
snippet editors without moving either. Manual check 7.12 sits beside 7.11, which
is this same bug on the files screen's picker, and says what the worse failure
would look like: a picker that moves rather than one that does not notice.

docs/manual-checks.md

@@ -915,6 +915,25 @@ add a bucket — then come back.
 **Failure means:** the screen has gone back to copying the vault's lists once at unlock. Covered by
 `TheTransfersScreen_FollowsTheVaultsHostList`; this is the version of it with a real picker in front of it.
 
+### 7.12 A key made now can be bound in the editor that is already open
+
+The same check one screen over, and the ordinary way round: start editing a host, type a port into it, then go
+to KEYS and add a key — or a password, or a tag — and come back to HOSTS. Repeat it with a group's editor open
+instead of a host's.
+
+**Pass:** the editor is still open with the port still in it, and the new key is in the AUTHENTICATION picker
+straight away. Choosing it and saving binds the host. A new tag is a chip among the others, unworn.
+
+Then the other half, which matters more: with a host that already authenticates with a key, open its editor
+and add a *second* key. **Pass:** the picker still reads the first one, and saving leaves the host bound to it.
+
+**Failure means:** an editor that has to be cancelled and reopened before it can see what was just made — the
+pickers went back to being snapshots taken when the editor opened, which was defensible only while the two
+screens refused each other. See `VaultViewModel.RefreshOpenEditors`, and
+`AKeyAddedWithTheHostEditorOpen_AppearsInItsAuthenticationPicker` for the same thing asserted against view
+models. A picker that *moves* instead — landing on the key that just arrived, or back on "Password (ask each
+time)" — is the worse failure of the two: it rebinds a host as a side effect of somebody else's sync.
+
 ---
 
 ## Phase 8 — Adding and removing on the phone's host list