Add /me and enrollment with the identity-provider key binding (M1)

The last backend piece of M1. A client can now log in, discover it must
enroll, publish its identity key, and get a usable personal vault.

Enrollment is one indivisible act. One transaction writes the key, its
wraps, the device, the key log entry, the vault and the vault key grant,
because none of them is useful alone: a key with no vault leaves a user
unable to store anything, and a vault with no grant is a container nobody
can ever open -- including its owner, since only the client can wrap the
key and it has already moved on.

Two independent checks run, and neither substitutes for the other. The
Ed25519 self-signature proves possession of the private key. The
identity-provider binding proves whose key it is: the client hashed its
statement, used the hash as an OIDC nonce, and the resulting ID token is
the provider's signature over exactly those public keys. This server
cannot mint that signature, so it cannot invent a key for a user who never
enrolled -- which is the attack that would otherwise let an operator read
every vault by publishing its own key as yours.

The binding token is stored verbatim, not just summarised. Clients must
repeat the check against the provider's JWKS fetched directly, and storing
only our conclusion would ask them to trust the server about the one
question the design exists to avoid trusting it about.

Key log appends take a deployment-wide advisory lock. The falsification
matters more than the passing test: with the lock removed,
Enroll_ConcurrentEnrollmentsByDifferentUsers_LeaveAnUnbrokenChain fails
with entry 11 linked to the wrong predecessor. Different users trip no
unique index, so without serialising they all read the same head and the
chain forks -- indistinguishable from the key substitution the log exists
to make detectable, and permanent, because the log is append-only.

Enrollment is idempotent. Vault ids and keys are client-chosen, so a
client whose response was lost re-sends the identical body and gets the
identical result. Without that, a lost response leaves a user enrolled
against a vault they never learned the id of.

Contract change, breaking the v0.1 freeze deliberately. EnrollmentRequest
had DevicePublicKey but no wrap to go with it, which is unsatisfiable:
only the holder of the secret bundle can seal it, so the server could
never fill the gap. Added DeviceWrappedPrivateKey, and PersonalVault so
enrollment can be atomic rather than leaving an unopenable vault behind
two endpoints that do not exist yet. No client exists and no package is
published, which is exactly when PublicAPI.Unshipped.txt expects this.

Sync now requires the Enrolled policy, which until now was a stub whose
name promised a check it never made. The sync denial tests use enrolled
intruders instead of unenrolled ones -- an unenrolled caller is stopped
before the vault check runs, which would have left those tests passing
without exercising the thing they exist to prove.

Also fixed: omitting kdfParameters from the JSON body was a 500. A
record's non-nullable parameters are a compile-time promise, not a runtime
one.

268 tests pass, zero warnings on a clean rebuild, format clean.

src/DodoSSH.Contracts/Enrollment.cs

@@ -53,6 +53,40 @@ public sealed record KeyStatement(
     DateTimeOffset CreatedAt,
     string DeviceName);
 
+/// <summary>
+/// The personal vault a client creates as part of enrolling.
+/// </summary>
+/// <remarks>
+/// <para>
+/// The vault key is generated on the client and sealed to the user's own X25519 key, so the
+/// server cannot produce this and cannot verify that <see cref="WrappedVaultKey"/> contains
+/// anything in particular. It stores the bytes and the signature that attributes them.
+/// </para>
+/// <para>
+/// <see cref="VaultId"/> is chosen by the client, not the server. That is what makes enrollment
+/// safely retryable: a client whose request timed out re-sends the identical body and gets the
+/// identical result, instead of accumulating a second vault it never learns about. It is also
+/// required by the grant signature, which covers the vault id — see docs/crypto.md §7.
+/// </para>
+/// </remarks>
+/// <param name="VaultId">Client-generated UUIDv7 for the new vault.</param>
+/// <param name="Name">Display name. Plaintext, as all vault names are.</param>
+/// <param name="WrappedVaultKey">
+/// The vault key sealed to the enrolling user's own encryption key. Opaque to the server.
+/// </param>
+/// <param name="GrantSignature">
+/// Ed25519 signature over the canonical grant tuple, by the key being enrolled. A self-grant
+/// carries no key log head, because there is no third party whose key could have been
+/// substituted.
+/// </param>
+/// <param name="GrantedAt">Signing timestamp, part of the signed tuple.</param>
+public sealed record PersonalVaultRequest(
+    Guid VaultId,
+    string Name,
+    byte[] WrappedVaultKey,
+    byte[] GrantSignature,
+    DateTimeOffset GrantedAt);
+
 /// <summary>A request to enroll a user's first identity key pair.</summary>
 /// <param name="Statement">The key statement.</param>
 /// <param name="StatementSignature">Ed25519 self-signature over the statement.</param>
@@ -68,10 +102,18 @@ public sealed record KeyStatement(
 /// X25519 public key of this device, so the bundle can also be wrapped to the device and
 /// unlocked without re-entering the passphrase.
 /// </param>
+/// <param name="DeviceWrappedPrivateKey">
+/// The same bundle sealed to <paramref name="DevicePublicKey"/>. Required whenever a device key
+/// is supplied: only the holder of the bundle can produce this, so a device key without its wrap
+/// registers a device that can never unlock anything.
+/// </param>
 /// <param name="RecoveryWrappedPrivateKey">
 /// The same bundle sealed under a recovery-code-derived key.
 /// </param>
 /// <param name="RecoveryKdfParameters">Parameters for the recovery wrap.</param>
+/// <param name="PersonalVault">
+/// The personal vault to create, with its key already wrapped to the enrolling user.
+/// </param>
 public sealed record EnrollmentRequest(
     KeyStatement Statement,
     byte[] StatementSignature,
@@ -79,8 +121,10 @@ public sealed record EnrollmentRequest(
     byte[] WrappedPrivateKey,
     KdfParameters KdfParameters,
     byte[]? DevicePublicKey,
+    byte[]? DeviceWrappedPrivateKey,
     byte[]? RecoveryWrappedPrivateKey,
-    KdfParameters? RecoveryKdfParameters);
+    KdfParameters? RecoveryKdfParameters,
+    PersonalVaultRequest PersonalVault);
 
 /// <summary>Result of a successful enrollment.</summary>
 /// <param name="UserId">The user's identifier.</param>