Sync credentials as a vault item type, and bind one to a host

Closes the largest remaining M1 gap in the data layer: a username and password
can live in the vault, sync between machines, and be named by a host as how it
authenticates. What is not here is the interface for creating one — see the end
of this message.

The third item type, and the first one that cost almost nothing to add. Server:
a VaultCredential row, an EF configuration, a migration, and a CredentialKind.
Client: a secret, a codec, a merge, a cipher, a kind, a repository facade and a
session property. No new reconciliation logic, no change to the sync engine, no
client cache migration. That was the whole point of the item-kind seam, and this
is the evidence it holds.

The narrowest type of the three on plaintext, and not for symmetry. A host has a
deliberate concession — the relay needs an address it can resolve. A key has a
fingerprint, public by nature, which this client still declines to send. A
password has no part that is safe to expose: not its length, not a hash, not a
hint. So CredentialKind refuses every plaintext field there is, hydrates none,
and the table has no column to put one in.

HostSecret.CredentialId is the password counterpart of SshKeyId, and the two are
mutually exclusive. SSH itself would happily try a key and fall back to a
password, but a host naming both leaves "how does this authenticate?" without a
single answer — the interface, the connect path and the user would each be free
to guess differently. TryValidate refuses it. One consequence was not
anticipated: "a full host" stops being a coherent idea, which is what broke
AFullHost_RoundTrips and is now written into that test.

The schema version became a ladder rather than a maximum: credential-bound is 3,
key-bound is 2, neither is still 1. Adding credentials therefore does not drag
every key-bound host in every vault onto a version that clients understanding
keys perfectly well would refuse to edit. A test pins exactly that, because it is
the property the whole content-dependent-version rule exists to provide, and the
obvious implementation would quietly lose it.

Two tests had become false and said so:

- Push_AnUnsupportedEntityType_IsInvalidNotAFailedBatch used Credential as its
  example of a type this server does not implement. It now asks the server's own
  registry what is still missing, so it cannot go stale again, and skips with a
  reason if that set ever empties.
- ThePullFilterNamesEveryTypeThisBuildSynchronises pinned the exact list, which
  is what it is for.

Also fixes ten nullable warnings — eight in SyncEndpointTests, two in a test file
added earlier today. Neither set was introduced here; both were invisible until
an unrelated change forced their project to recompile, which means the
zero-warning claims made earlier in this work only ever covered what happened to
be rebuilt.

777 tests green. Zero warnings, dotnet format clean.

Not done, and deliberately: the credential interface. The vault column is 340
pixels wide and already holds two lists and two editors, kept from clipping its
own buttons at the window's minimum height only by the one-editor-at-a-time rule
added earlier today. A third list and a third editor would recreate that defect
rather than avoid it, so the column needs a shape decision first. Credentials
sync; they cannot yet be created in the interface.

src/DodoSSH.Client.Domain/CredentialSecretMerge.cs

@@ -0,0 +1,111 @@
+namespace DodoSSH.Client.Domain;
+
+/// <summary>The merged credential, and everything that had to be overridden to produce it.</summary>
+/// <param name="Merged">The credential to store and push.</param>
+/// <param name="Conflicts">Empty when the two sides were reconcilable field by field.</param>
+public sealed record CredentialMergeResult(
+    CredentialSecret Merged,
+    IReadOnlyList<HostFieldConflict> Conflicts)
+{
+    /// <summary>Whether anything had to be overridden.</summary>
+    public bool HasConflicts => Conflicts.Count > 0;
+}
+
+/// <summary>
+/// Merges two divergent versions of a credential against the version they both started from.
+/// </summary>
+/// <remarks>
+/// <para>
+/// Every field is a scalar, so this is the same shape as <see cref="SshKeySecretMerge"/> and reuses
+/// <see cref="HostFieldConflict"/> for the same reason: the conflict log, the storage behind it and the
+/// interface that shows it are shared, and a parallel record with identical members would have to be mapped
+/// at every boundary.
+/// </para>
+/// <para>
+/// <b>The password never reaches the conflict log.</b> Reported as having differed and nothing more, exactly
+/// as <c>SshKeySecretMerge</c> does for key material — and here the case for it is if anything plainer, since
+/// a discarded password is very often still the live password on some other system. The user loses nothing
+/// they could act on: nobody reconciles two passwords by reading them side by side.
+/// </para>
+/// <para>
+/// The username is shown, because it is not a secret and knowing which of two accounts the merge dropped is
+/// exactly what makes the notice useful.
+/// </para>
+/// </remarks>
+public static class CredentialSecretMerge
+{
+    /// <summary>Produces the merged credential.</summary>
+    /// <param name="ancestor">The version both sides branched from.</param>
+    /// <param name="local">The pending local version.</param>
+    /// <param name="remote">The server's current version.</param>
+    public static CredentialMergeResult Merge(
+        CredentialSecret ancestor,
+        CredentialSecret local,
+        CredentialSecret remote)
+    {
+        ArgumentNullException.ThrowIfNull(ancestor);
+        ArgumentNullException.ThrowIfNull(local);
+        ArgumentNullException.ThrowIfNull(remote);
+
+        var conflicts = new List<HostFieldConflict>();
+
+        var merged = new CredentialSecret
+        {
+            // Null-forgiving on the two required fields, as the host and key merges do for the same reason:
+            // the merge returns one of its three inputs, and all three are non-null by construction.
+            Label = Resolve(
+                nameof(CredentialSecret.Label),
+                ancestor.Label,
+                local.Label,
+                remote.Label,
+                conflicts,
+                redact: false)!,
+            Password = Resolve(
+                nameof(CredentialSecret.Password),
+                ancestor.Password,
+                local.Password,
+                remote.Password,
+                conflicts,
+                redact: true)!,
+            Username = Resolve(
+                nameof(CredentialSecret.Username),
+                ancestor.Username,
+                local.Username,
+                remote.Username,
+                conflicts,
+                redact: false),
+            Notes = Resolve(
+                nameof(CredentialSecret.Notes),
+                ancestor.Notes,
+                local.Notes,
+                remote.Notes,
+                conflicts,
+                redact: false),
+        };
+
+        return new CredentialMergeResult(merged, conflicts);
+    }
+
+    private static string? Resolve(
+        string name,
+        string? ancestor,
+        string? local,
+        string? remote,
+        List<HostFieldConflict> conflicts,
+        bool redact)
+    {
+        var merge = ThreeWayMerge.Scalar(ancestor, local, remote, StringComparer.Ordinal);
+
+        if (merge.IsConflicted)
+        {
+            conflicts.Add(new HostFieldConflict(
+                name,
+                MergeSide.Local,
+                redact ? "(kept the server's value)" : merge.Value ?? "(none)",
+                redact ? "(a different value was discarded)" : merge.Discarded ?? "(none)",
+                DiscardedWasRemoval: false));
+        }
+
+        return merge.Value;
+    }
+}