No principal cache: every write replays full history from cold storage

Every write currently reconstructs a principal's full history from cold storage before applying a new commit — there is no in-memory principal cache:

https://github.com/Cyphrme/Cyphr/blob/61c19e1/rs/cyphr-storage/src/engine/mod.rs#L301-L404

This is the load path called on every `submit_commit`, so cost grows linearly with an account's history length and sets the real latency budget for anything layered on top of it (write serialization, request handling under load).

Not a defect today — no deployed data exists yet, and the storage engine's write path is otherwise sound. It becomes a real concern once a server needs to sustain meaningful write throughput per account. Fix shape: an in-memory principal cache keyed by principal id, invalidated or updated on write, with an explicit eviction/consistency story once concurrent access is real.

Deliberately deferred to the server-implementation effort, which will also introduce per-principal write serialization (see #27) that this caching strategy needs to be designed alongside, not before.

Start with rs/cyphr-storage/src/engine/mod.rs around lines 301-404 and trace the load path used by submit_commit. Read issue #27 alongside this path, since the cache is explicitly deferred to the server effort and must be designed with per-principal write serialization. Done requires an agreed cache, eviction, invalidation or update, and concurrency-consistency design.

Written by the indexing model from the issue text.