Add data model, DbContext and initial migration (M1)

Schema for identity, vaults, grants, hosts and the sync change log, verified against a
real PostgreSQL 18 container rather than an in-memory provider: partial unique indexes,
CHECK constraints, citext and identity-always columns are all provider behaviour that an
in-memory fake would not exercise.

Invariants pushed into the database, so they hold even when application code has a bug:
- ck_host_relay_target is a security boundary, not tidiness. A host may carry a plaintext
  hostname and port ONLY when relay is deliberately enabled. Both directions are tested;
  the important one is that relay-disabled hosts cannot carry an address, since otherwise
  a bug would silently give the server infrastructure visibility it was never granted.
- ck_vault_owner: exactly one of owner_user_id or team_id, or permission resolution would
  have no defined answer.
- ck_vault_key_grant_recipient: member grants name a user; recovery and escrow grants are
  wrapped to a key and must not.
- ck_user_key_wrap_kdf: a password-derived wrap without its parameters is permanently
  unopenable, so a partial write is rejected outright.

Present from the first migration on purpose:
- GrantKind (Member/Recovery/Escrow). Recovery cannot be bolted on later — every vault
  created before it existed would be unrecoverable by design.
- team and team_membership, though team features are M3. Adding them later would mean
  introducing a foreign key on a live vault table.
- Host.ContentKeyId, reserved for per-item content keys wrapped to individual users.
- user_key as its own table, so key rotation does not require altering the user row.

Two things verified rather than assumed:
- Npgsql's UseXminAsConcurrencyToken helper no longer exists in EF 10, so xmin is mapped
  directly in XminConcurrency. The generated migration *looks* like it creates an xmin
  column; it does not. Confirmed by inspecting pg_attribute (attnum -2, a system column)
  and by grepping the emitted DDL. A test pins both, because had it created a real column
  PostgreSQL would have rejected the name.
- EF Core is now pinned centrally. The Npgsql provider asks for 10.0.4 while
  EntityFrameworkCore.Design pulls 10.0.10, and because Design is PrivateAssets=all that
  higher version does not flow to referencing projects — producing a CS1705 in any test
  project referencing Infrastructure.

Also commits artifacts/schema/v0.1.sql, the idempotent script, as the baseline for future
upgrade tests.

Verified: 0 warnings, 122 tests pass (27 new against Postgres), format clean.

src/DodoSSH.Domain/Vaults.cs

@@ -0,0 +1,133 @@
+namespace DodoSSH.Domain;
+
+/// <summary>
+/// A container of encrypted items sharing one vault key.
+/// </summary>
+/// <remarks>
+/// The vault name is plaintext, unlike item names. A user has to be able to pick a vault before
+/// anything is decrypted, and vault names are few and low-signal compared with a full host
+/// inventory.
+/// </remarks>
+public sealed class Vault
+{
+    /// <summary>Primary key.</summary>
+    public Guid Id { get; set; }
+
+    /// <summary>Display name.</summary>
+    public string Name { get; set; } = string.Empty;
+
+    /// <summary>Whether this belongs to a user or a team.</summary>
+    public VaultOwnerKind OwnerKind { get; set; }
+
+    /// <summary>Owning user, for a personal vault.</summary>
+    public Guid? OwnerUserId { get; set; }
+
+    /// <summary>Owning user, for a personal vault.</summary>
+    public UserAccount? OwnerUser { get; set; }
+
+    /// <summary>Owning team, for a team vault.</summary>
+    public Guid? TeamId { get; set; }
+
+    /// <summary>Owning team, for a team vault.</summary>
+    public Team? Team { get; set; }
+
+    /// <summary>
+    /// Current key generation. Bumped on rekey, and part of every item's AAD, so a server cannot
+    /// roll a row back to a superseded generation.
+    /// </summary>
+    public int KeyGeneration { get; set; } = 1;
+
+    /// <summary>Whether a membership or key change has left this vault needing a rekey.</summary>
+    public bool RekeyRequired { get; set; }
+
+    /// <summary>Why a rekey is pending.</summary>
+    public RekeyReason RekeyReason { get; set; }
+
+    /// <summary>Creation timestamp.</summary>
+    public DateTimeOffset CreatedAtUtc { get; set; }
+
+    /// <summary>Last modification timestamp.</summary>
+    public DateTimeOffset UpdatedAtUtc { get; set; }
+
+    /// <summary>Soft-delete marker.</summary>
+    public DateTimeOffset? DeletedAtUtc { get; set; }
+
+    /// <summary>Wrapped vault keys, one per recipient per generation.</summary>
+    public ICollection<VaultKeyGrant> KeyGrants { get; } = [];
+
+    /// <summary>Hosts in this vault.</summary>
+    public ICollection<Host> Hosts { get; } = [];
+}
+
+/// <summary>
+/// A vault key wrapped to one recipient, for one key generation.
+/// </summary>
+/// <remarks>
+/// <para>
+/// The server stores <see cref="WrappedKey"/> verbatim and cannot verify that it is the correct
+/// vault key. A malicious granter can seal garbage; the recipient detects it on first unwrap as a
+/// tag failure, and <see cref="Signature"/> names who did it. Detectable and attributable is the
+/// right failure mode here — silent is not achievable, since verification would require the
+/// server to hold the key.
+/// </para>
+/// <para>
+/// <see cref="GranterKeyFingerprint"/> and <see cref="KeyLogHead"/> are recorded so a recipient
+/// can check both who wrapped this and what view of the key log they held at the time.
+/// </para>
+/// </remarks>
+public sealed class VaultKeyGrant
+{
+    /// <summary>Primary key.</summary>
+    public Guid Id { get; set; }
+
+    /// <summary>The vault.</summary>
+    public Guid VaultId { get; set; }
+
+    /// <summary>The vault.</summary>
+    public Vault? Vault { get; set; }
+
+    /// <summary>Key generation this grant is for.</summary>
+    public int KeyGeneration { get; set; }
+
+    /// <summary>Why this grant exists: a member, a recovery key, or escrow.</summary>
+    public GrantKind Kind { get; set; }
+
+    /// <summary>Recipient, for a member grant.</summary>
+    public Guid? RecipientUserId { get; set; }
+
+    /// <summary>Recipient, for a member grant.</summary>
+    public UserAccount? RecipientUser { get; set; }
+
+    /// <summary>
+    /// Fingerprint of the exact public key this was wrapped to, so a later key rotation
+    /// invalidates the grant explicitly rather than silently.
+    /// </summary>
+    public byte[] RecipientKeyFingerprint { get; set; } = [];
+
+    /// <summary>The vault key, sealed to the recipient. Opaque.</summary>
+    public byte[] WrappedKey { get; set; } = [];
+
+    /// <summary>Who created this grant.</summary>
+    public Guid GranterUserId { get; set; }
+
+    /// <summary>Fingerprint of the granter's identity key.</summary>
+    public byte[] GranterKeyFingerprint { get; set; } = [];
+
+    /// <summary>Key log head the granter observed. Enables fork detection.</summary>
+    public byte[]? KeyLogHead { get; set; }
+
+    /// <summary>
+    /// Ed25519 signature by the granter over the canonical grant tuple. Verified by clients, not
+    /// by the server: server-side verification would be a convenience, never the boundary.
+    /// </summary>
+    public byte[] Signature { get; set; } = [];
+
+    /// <summary>Grant state.</summary>
+    public GrantState State { get; set; }
+
+    /// <summary>Creation timestamp.</summary>
+    public DateTimeOffset CreatedAtUtc { get; set; }
+
+    /// <summary>Revocation timestamp.</summary>
+    public DateTimeOffset? RevokedAtUtc { get; set; }
+}