Summary

A disaggregated follower accepts transactions whose commit timestamp is at or below the timestamp of its most recently adopted checkpoint. This permits a follower operation to be committed behind the checkpoint frontier.

Checkpoint pickup updates the disaggregated storage's last checkpoint timestamp, but transaction timestamp validation uses the follower's configured stable/recovery timestamp. If that timestamp has not advanced to the adopted checkpoint, the follower may accept an older commit timestamp.

Reproduction

1. Create a layered table, write data at timestamp 10, and adopt the initial checkpoint on a follower.
2. Set the leader's stable timestamp to 30 and have the follower adopt that checkpoint.
3. On the follower, truncate a range in a transaction with commit timestamp 20.

The follower currently accepts the truncate. This was reproduced in test/suite/test_layered_fast_truncate22.py using the disaggregated PALite scenario.

Expected behavior

The follower should reject commits at or below its adopted checkpoint timestamp, or otherwise maintain an equivalent invariant that prevents writes from committing behind the checkpoint frontier.