Bind an SSH key to a host instead of picking one per connection

A host now names the key it authenticates with, or none, as a field in its
encrypted payload — so the choice follows the host to every machine rather than
being made again each time somebody connects. The per-connection "Use key"
switch it replaces was a stopgap for not having this, and keeping both would
have left two mechanisms answering one question.

This is the first payload schema version bump, and it does not work the obvious
way. A host is written at the *lowest* schema version that can represent it: one
that binds a key is written at 2, one that does not is still written at 1, byte
for byte as it was before the field existed. The version is what makes an older
client refuse to edit an item, so stamping 2 unconditionally would mean
upgrading a single machine and renaming a single host made that host uneditable
on every machine that had not upgraded yet. Confining the cost to the hosts that
actually use the field is the difference between a team noticing a bump and a
team being blocked by one. HostSecretCodec states the rule so the next field
added follows it, and a test pins the version-1 bytes against a literal rather
than against the codec, because the claim is about history: every host already in
every vault has to re-encode to what it encoded before, or the first sync after
an upgrade would push the whole vault as changed.

A binding is an item id, not a copy of the key — a second copy of a private key
is one that goes stale — which means the reference can dangle when the key is
deleted on another machine. Both places that meets are handled the same way, by
refusing rather than falling back:

- Connecting to a host whose key is gone is refused outright. A host somebody
  deliberately set up for key-only access must not quietly start offering a
  password.
- Opening such a host in the editor keeps the binding, selected, labelled as
  missing. The quieter version of the same failure is someone editing the port
  and saving, silently converting the host to password authentication with
  nothing ever having said so.

Two things this found by being falsified:

- The merge was untested for the new field, and "just take the server's value"
  passed the entire suite — a local binding change would have been discarded with
  no conflict recorded. HostSecretMergeTests already had a test written for
  exactly this class of omission; it simply had not been extended.

- Adding a nullable field exposed a defect in HostSecretMerge.Field: it
  short-circuited when the discarded value was null, so the formatter never ran
  for the one case where null is a value rather than an absence, and a field
  whose absence has a name could not report it. Now the formatter always runs,
  and "no key" appears in the conflict log where an empty string used to.

Also fixes eight nullable warnings in SyncEndpointTests left by the server-side
SSH key commit, which had omitted the null-forgiving operator the rest of that
file uses. They were invisible until an unrelated change forced the project to
recompile.

The end-to-end slice now binds its host to its key, so a schema-version-2
payload goes through the real API, the real PostgreSQL and back out on a second
machine.

745 tests green. Zero warnings, dotnet format clean.

README.md

@@ -128,14 +128,14 @@ skipped and cannot be recovered from the server. You can then add a host and ope
 admin console is at `http://localhost:18080` (`admin` / `admin`).
 
 You can also add an SSH key, which is stored in the vault like a host and synced the same way: paste the
-private key, tick **Use key** next to Connect, and the selected key authenticates instead of a password.
+private key, then edit a host and pick that key from its **key** dropdown. From then on that host
+authenticates with it — on every machine, since the choice travels inside the host's encrypted payload —
+and its password box disappears.
 
 Three of M1's known gaps are visible immediately, so they are worth expecting rather than diagnosing:
 password authentication asks for the password every time, because credentials are not a synced entity type
-yet (keys are — passwords are not); a key is chosen per connection rather than remembered per host, because
-binding one to a host needs a new field on the host payload and so a schema version bump; and unlock asks
-for the passphrase on every launch, because no device key is registered. Host key trust also lasts one
-session, because known hosts do not live in the vault yet.
+yet (keys are — passwords are not); host key trust lasts one session, because known hosts do not live in the
+vault yet; and unlock asks for the passphrase on every launch, because no device key is registered.
 
 ### End-to-end verification
 
@@ -203,10 +203,15 @@ off-Windows.
 
   Known gaps in the client, stated rather than implied by the interface: credentials are not a synced
   entity type yet, so password authentication still asks for the password each time — SSH keys *are*
-  synced, and are the way to connect without typing anything; a key is picked per connection rather than
-  bound to a host, which needs a field on the host payload and therefore a schema version bump; known host
-  keys live in memory for one session instead of in the vault; and no device key is registered, so the
-  passphrase is needed on every launch until the OS keystore is wired.
+  synced, and binding one to a host is the way to connect without typing anything; known host keys live in
+  memory for one session instead of in the vault; and no device key is registered, so the passphrase is
+  needed on every launch until the OS keystore is wired.
+
+  Binding a key introduced the first payload schema version bump, and it is worth knowing how it behaves:
+  a host is written at the *lowest* schema version that can represent it, so only hosts that actually bind
+  a key are written at version 2 and become read-only on an older build. Hosts that do not are still
+  written at version 1, byte-identically to before the field existed — which is what keeps upgrading one
+  machine from making a team's whole vault uneditable everywhere else.
 - **M2 — full personal vault**, robust sync, relay.
 - **M3 — teams**, sharing, ACLs.
 - **M4 — hardening and ops**, packaging, self-hosting guide.