While testing WT-9123 I hit a failure in which one of two checkpoint cursors read the wrong stable timestamp out of a checkpoint. The problem was that it was possible for the cursor open to read the stable timestamp from checkpoint 1, and then for checkpoint 2 to finish and write both the stable timestamp and the snapshot to the metadata, after which the cursor open read the snapshot from checkpoint 2. It then accepts this instead of retrying, because the logic that allows for the possibility that the stable timestamp wasn't set at all in the checkpoint was too permissive. The solution is to read the timestamps after the snapshot (the opposite order from how they're written) and rely on the fact that if checkpoint 2 has no stable timestamp, then checkpoint 1 can't have either.