feat(phylake): add the custody store with B1–B5 transactions and recovery

[forkwright]

What changed

crates/phylake/src/store is the D5 custody store, specified by docs/design/custody-store.md. It runs on one fjall 3.1 SingleWriterTxDatabase with 15 keyspaces. Every write transaction sets PersistMode::SyncAll, and the single-writer lock serializes the state checks.

• Opening the store. The store holds a plaintext meta record: format, schema version, active root key id, KDF salt and key check. Open validates those fields before any write and fails closed:

  • SchemaTooNew
  • MigrationRequired (schema v1 is the first, so migrate arrives with the first schema change)
  • StoreLocked

  A new store directory is created with mode 0700. The fjall lock allows one open store at a time.

• Records. Records are rkyv structs owned by phylake, read back through validated access. Each value is sealed with an AAD that binds schema version, record kind, key id, keyspace and record key.

  • Store-sealed: directory and lifecycle records.
  • Tenant-sealed: blobs, side records, session index, idempotency bindings and per-tenant audit.

  Every record key built from tenant, session or idempotency components is a keyed HMAC, and tenant-scoped keys include the tenant. The target URL is never persisted.

• Invocation lifecycle. Each step is one transaction, checked against epitrope's next_state, and writes its terminal audit entry in the same transaction.

  • B1: runs the idempotency check first. The store binds the caller's digest to the grant, capability, session, target and cost. It then authorizes with epitrope, debits the reservation from every ledger in the plan, and persists the intent.
  • B2: dispatch.
  • B3: writes the blob at a tenant-keyed address, plus a pending side record that is not yet visible.
  • B4: the atomic publish point. It writes the side record, locator and session index. The artifact id is the invocation id.
  • B5: settles, releases or marks UnknownEffect, and records a typed Terminal (Settled{failure} / Released{reason} / UnknownEffect).
  • A refused call writes only audit, and a dry-run writes nothing.

• Recovery. recover() applies epitrope's recovery_action through the same transitions: B1 becomes Released(Abandoned), B2 becomes UnknownEffect (charged the whole reservation), and B3 and B4 roll forward. Running it again changes nothing.

• Directory. Tenant registration (with a freshly wrapped data key), a root grant, grant issue and revoke (checked by epitrope inside the transaction and audited either way), and session create and fork with lineage. Each write is idempotent by a caller-chosen id.

• Reads. Chunked artifact reads and per-session listings. Missing and unpublished artifacts look the same. audit_query implements the D17.7 scopes (All, OwnAndOwnedSessions), with a session filter and paging. StoreSnapshot implements epitrope's Snapshot and the wire server's TenantDirectory.

• Failpoints. A Failpoint trait with before/after commit hooks for B1 through B5.

• Documentation. custody-store.md now records:

  • the sealing-scope table, and what a crypto-shred leaves readable: ids, amounts, lineage, states and timestamps, but no acquired content, idempotency binding or per-tenant audit;
  • the physical blob key;
  • the artifacts record kinds;
  • the tenant key cache;
  • audit reads.

  UnknownEffect is now described as charging the whole reservation in both the custody and contract docs.

Why

Phase 01 S2's custody clauses require three things. Every invocation authorizes, reserves atomically and persists intent before any external effect. Every outcome settles or releases exactly once. A crash at any durability boundary leaves an explicit state that can be recovered, and replay never repeats an external action.

Dependencies

Crate	Why
fjall 3.1 (default features off)	The D5 engine under D17.14's STORAGE-TIERS migration exception. It is pure Rust, with atomic multi-keyspace transactions and SyncAll durability.
epitrope, syntheke (path)	Authorization and the contract types.
rkyv	Record encoding, the same validated format family as the wire.

deny.toml adds:

• Licenses: 0BSD (varint-rs) and BSL-1.0 (xxhash-rust).
• Skips: hashbrown 0.14 and 0.16. rkyv's alloc needs 0.17, while fjall's map dependency and lsm-tree's quick_cache pin older versions. Each skip has a retirement condition.

Stage and acceptance

Phase 01 S2. This PR proves the following acceptance clauses at the store boundary:

• "crash/reopen at each durability boundary";
• "replay of same invocation";
• "dry-run no effects";
• "cross-tenant read and metadata denial";
• "every outcome settles or releases once".

Proof (toolchain 1.97.1)

• Workspace: 416 tests pass (phylake has 145). They cover:
  • Every row of the failure-injection table: a crash before or after each Bn commit, then reopen and recover. Each row asserts the exact state, the ledger values, exactly one terminal audit entry, visibility, and that the producer call counter is unchanged. A second recovery leaves a byte-identical logical dump.
  • The exact Released{reason} for every release path.
  • Concurrency: 8 threads released together by a barrier against a ceiling of 3. Exactly 3 succeed, and every ledger shows exactly 3.
  • Idempotency: a replay performs no writes. The same digest under a different grant, target or cost returns Conflict.
  • A raw scan of the whole fjall directory finds zero hits for the envelope marker, URL, host, text view, idempotency key, envelope SHA-256, session id, schema id, or tenant bytes and ULID text. A positive control (the plaintext format tag) is found.
  • A record moved under another key fails to open.
  • The audit query scopes.
• clippy -D warnings, cargo deny check, cargo tree -d (documented skips only), rustdoc with -D warnings, fmt and the doc checks are clean.
• An independent adversarial review fixed these defects:
  • release reasons were recorded wrongly;
  • recovery could stall permanently on a colliding artifact id;
  • the idempotency binding was incomplete;
  • the request digest would have stayed readable after a crypto-shred;
  • repeating a grant issue was not idempotent;
  • B2 settle accepted any failure kind.

Rekey, crypto-shred and backup follow in the next slice.