feat(fjall): projection SnapshotStore<Vec<u8>, GlobalSeq> adapter (#164)

[joeldsouzax]

Closes #164.

What

Adds a fjall-backed SnapshotStore<Vec<u8>, GlobalSeq> for projection state, behind a new projection feature. A projection's folded state and the $all GlobalSeq it was folded up to are committed together into one value under one key in a dedicated projections partition.

Design

• Distinct partition. projections is a separate point-read keyspace from snapshots, so a projection id can never collide with an aggregate-snapshot id sharing the same bytes.
• Coherent coexistence. The two SnapshotStore impls on FjallStore are distinct trait instantiations (P = Version vs P = GlobalSeq) — no coherence conflict.
• Atomicity for free. commit is a single-key insert of the combined [u32 LE schema_version][u64 BE position][payload] value (the existing snapshot blob layout — position is the GlobalSeq's u64, no new encoder). A half-write of state without its position is unrepresentable, same guarantee as the snapshot path.
• hydrate returns None on schema-version mismatch, parity with the snapshot impl. A stored GlobalSeq of 0 is impossible, so a well-formed header carrying a zero position maps to CorruptValue.

Incidental

• Partitions::new now takes the event-frame pair as one (events, events_global) tuple, keeping arity within the project's too-many-arguments-threshold = 5 after the new projections keyspace. That forfeits const (const eval can't drop the tuple), which was never load-bearing here (new is only called at runtime from open).
• hydrate call sites in both fjall test files are disambiguated (turbofish) because under --all-features both SnapshotStore impls are in scope and hydrate's P is return-position only.

Tests (acceptance)

• FjallStore: SnapshotStore<Vec<u8>, GlobalSeq> behind projection, on a projections partition
• Atomic commit (state + GlobalSeq in one value)
• hydrate returns None on schema-version mismatch
• Lifecycle: commit → reopen → hydrate returns the same (GlobalSeq, state)
• Defensive: corrupt/too-short bytes → CorruptValue, not a panic (white-box); plus a zero-GlobalSeq corruption test

9 public-API tests (roundtrip, overwrite, reopen lifecycle, schema mismatch, GlobalSeq boundaries incl. INITIAL/u64::MAX, empty state, isolation) + 2 white-box defensive tests. Green under nix flake check and cargo clippy/test -p nexus-fjall --all-targets --all-features.

🤖 Generated with Claude Code

[joeldsouzax]

Follow-up hardening after a principal-level self-review (rule 9 — measure/question rather than inherit):

1. Added the test that actually defends the design. The whole point of the separate projections partition is that an aggregate snapshot and a projection checkpoint sharing the same id bytes must not clobber each other — and the original suite only tested projection-vs-projection isolation. snapshot_and_projection_with_same_id_do_not_collide now commits both stores at id "shared-id" and asserts each hydrates its own value. It fails if the two partitions are ever merged (a shared keyspace would let the second commit overwrite the first). It needs both features, so the self dev-dependency now enables snapshot too — which also closes a pre-existing gap where snapshot_tests.rs never ran under the default-feature gate.

2. Restated atomicity structurally, not operationally. The earlier doc claimed "single-key insert is atomic." The real, stronger guarantee doesn't depend on fjall's fsync semantics: because state and position are one value under one key, a persisted checkpoint can never be ahead of the state it describes, so a lost commit (IoT power-loss) costs an idempotent re-fold, never a skipped event. Docs in write_projection, the impl module, and CLAUDE.md now say that.

Deferred to a design thread (not this PR): whether aggregate snapshots and projection checkpoints should keep sharing SnapshotStore<S, P> at all (the two-impl hydrate ambiguity is the symptom), and whether hydrate returning None on schema-mismatch — which for a projection means re-folding all of $all — should be a silent inherited behavior. Both trace back to the #163 unification.