feat(sphragis): define revocation as key rotation, not re-wrapping

[forkwright]

Closes #14

The defect

seal_for distributes a content key to a recipient set. It has no memory of
who has ever recovered that key, so re-running it over a smaller recipient
list only changes who receives the next wrap — a recipient who already
unsealed the key keeps it regardless. README.md and DECISION.md called that
operation revocation anyway, including a "cheap revoke" that reused the same
content key; src/seal.rs's own module doc made the same claim. The prior
revocation_excludes_device test never gave device 2 a wrap or let it
recover the key, so it proved recipient omission, not revocation of a
previously authorized device — exactly the gap the issue's evidence names.

kanon's projects/sphragis/vision.md makes the same claim
("revocation = re-run seal_for over the remaining recipients"). That file
lives in a different repo and this PR does not touch it, but it is now stale
planning prose and needs correcting on that side.

What this PR adds

A typed rotation protocol in src/rotate.rs, on the profile surface (no
hazmat, per #32's narrowed public API) — a typestate chain that makes the
stage ordering a compile error to violate:

1. New key — generate_content_key() (OS CSPRNG; _with_rng variant
   for injection, same pattern as seal_for/seal_for_with_rng).
2. Publish new wraps — PendingRotation::begin(epoch, &new_key, &old_key)
   then .publish_wraps_for(&retained_recipients). begin rejects a new key
   equal to the old one (SealError::ContentKeyUnchanged), compared via
   subtle::ConstantTimeEq since both operands are secret material — this
   is the crate's first direct secret-vs-secret comparison, so subtle
   becomes a direct (optional, preview-pq-gated) dependency; DECISION.md
   §6 is corrected, it previously stated the crate needed none.
3. Switch the epoch — PublishedWraps::commit().
4. Retire the old key — CommittedEpoch::retire_old_key(old_key), which
   drops (zeroizes) the orchestrating caller's own copy.

Wire-compatible: rotation calls the same seal_for_with_rng internals
seal_for does, so WrappedContentKey's CBOR shape and version don't move.

The adversarial test

tests/rotation.rs::rotation_actually_revokes_a_device_that_held_the_old_key:

• Device 2 is provisioned alongside device 1, and actually recovers the
  old content key via unseal (not just issued a wrap — genuinely holds
  the secret).
• Device 2's recovered key decrypts a payload encrypted under the old
  content key (the "still holds access to what it already had" half).
• Rotation runs, retaining device 1 only.
• The load-bearing assertion: device 2's old key, used against a payload
  encrypted under the new content key, fails to decrypt. Device 2 has no
  wrap in the new epoch (published.wraps().len() == 1) is asserted too,
  but the comment marks it explicitly as the weaker, already-true property —
  the failing decrypt is what makes this a revocation test rather than a
  recipient-omission test.
• Device 1 continues to work against the new epoch (happy path).

begin_rejects_unchanged_content_key and full_protocol_reaches_rotation_complete
cover the guard and the typestate's happy path.

What rotation does not protect — stated plainly, not left implicit

Ciphertext already written under the old content key stays readable by
anyone holding that key, forever. Rotation cannot retract a secret from
memory it does not control; it protects data written after the epoch
switch, not data written before it. This is in the module doc (top of
src/rotate.rs), README.md, and DECISION.md §11 — not just this PR body —
because a rotation API that let a reader believe it was retroactive would be
a worse failure than the mis-naming this issue exists to fix.

Design decisions the issue left open (surfaced, not chosen silently)

• Does rotation re-encrypt existing payloads, or only protect data going
  forward? Forward-only. Sphragis wraps content keys; it has never
  touched payload data and this PR doesn't change that — there is nothing
  for it to re-encrypt. If a consumer wants old data protected too, that's
  their own operation against their own store. This is the conservative
  reading, chosen explicitly and stated in the module doc rather than left
  for a reader to assume either way.
• Who allocates EpochId? The caller. Sphragis holds no state across
  calls, so it cannot allocate or validate a monotonic sequence — that
  already belongs to whatever store tracks "which wrap set is current."
  EpochId is an opaque u64 carried through the typestate chain
  unmodified.
• What does "atomically switch the epoch" mean for a crate with no
  storage? The consumer's own store transaction is the only thing that
  can make it atomic. PublishedWraps::commit() doesn't perform that
  transaction — what it guarantees is ordering: the type system refuses a
  CommittedEpoch (and therefore refuses retire_old_key) until commit()
  is called, so the old key can't be destroyed before the caller has at
  least acknowledged the new epoch is durably live. This is stated
  explicitly in commit()'s doc comment rather than implied.

Conformance

#[non_exhaustive] SealError gains one variant (ContentKeyUnchanged,
snafu + .context()/#[snafu(implicit)] location, matching every
existing variant). No unwrap/expect in library code. No as casts. No
indexing/slicing (tests/rotation.rs uses .get()/.first() throughout).
subtle::ConstantTimeEq for the one secret comparison. #![deny(missing_docs)]
holds; every public fallible fn has # Errors. cargo fmt --check is clean.

Build reality / observed state

metis is saturated by concurrent dispatch work (uptime load average
11–16 against 8 cores) for the duration of this session; a local
VGATE_CORE_BUDGET=6 cargo check --features preview-pq,hazmat --tests sat
queued at vgate admission the entire time and produced no output — never
admitted, not a failure. cargo fmt --check (no admission needed) is clean
on every changed file. I have not observed a green compile/test/clippy
locally; CI on this push is the first real signal — check the Actions run
on this PR before treating it as verified.