Feature: support merging checkpoints that were received out of sync

This is easiest to explain with an example timeline with two witnesses, A & B:

1. A sends checkpoint of size X
2. B sends checkpoint of size X
3. A sends checkpoint of size X+1
4. A sends checkpoint of size X+2
5. B sends checkpoint of size X+1

Asking for checkpoint with N=2 will give a checkpoint of size X, where a checkpoint of size X+1 should be possible.

The reason for this is that the distributor is optimized to only keep the latest checkpoint seen for each witness+log pair in the pool of checkpoints available for merging. If this is replaced before it is merged and promoted then it is lost forever.

There are a number of ways to go about fixing this, but they all risk making the size of the database unbounded in size, or increasing complexity. The current strategy is to wait to see if this appears to be a problem before taking on that risk/complexity.

This test case is covered in cmd/internal/distributor/distributor_test.go: TODO: N=2 can get historic version where both have been seen but not at same time

Start with cmd/internal/distributor/distributor_test.go and the TODO describing the out-of-sync checkpoint timeline. Trace the distributor's checkpoint pool behavior and evaluate the possible retention approaches mentioned in the issue. Done means an N=2 request can return the historic X+1 checkpoint after both witnesses have sent it, without introducing unacceptable unbounded database growth.