Replica session calibration

The history x=1, y=2, x=3 yields {}, {x:1}, {x:1,y:2}, {x:3,y:2}. Receipt of all three entries does not change visible state until apply advances. A follower applied at 1 can serve token 1 but must block token 2 or 3. A successful missing-key read returns None with its actual applied prefix; blocked/unavailable responses return no value or token.

After observing prefix 3, max(previous,3) preserves the session lower bound. Retaining only an earlier write token can permit a subsequent older prefix. Read-your-writes permits later overwrites, and monotonic prefixes are not pinned snapshots. Another user without your token may still read old state.

An offline leader and lagging followers require waiting, verified eligible routing or failure. None of those choices allows pretending a stale prefix meets the token. A token from another stream is rejected before availability is checked. The stream identifier assumes one history here; it is not an implemented failover epoch protocol.

A weak answer says “R+W>N means every read is fresh.” A passing answer separates the configured read rule from replication progress and explains the missing reconciliation assumptions. Strong evidence adds a migration or forked-history counterexample and identifies the unimplemented ownership/fencing mechanism. The model has no real network, disk, clock, election or concurrency; passing tests do not claim otherwise.

Repair with different overwrite order and follower positions after 48 hours. Preserve assistance and avoid presenting generated traces as actual server observations. Complete original partitioning and migration work before declaring the module complete.