Feature: Consider and document which log signature is propagated when checkpoints are combined

When creating a merged checkpoint, combine_signatures.go#Combine currently picks the first checkpoint as the basis to which the other witness signatures are added. This means that the log signature on this checkpoint will be the one on the merged checkpoint.

In the case where all witnesses have seen the same checkpoint but the log signature was different (which could be because of a non-deterministic signing algorithm, or because of something like the timestamps that are embedded in the Sunlight CT checkpoint signature scheme), this means that we are arbitrarily picking a log signature to "win". From a quick look at the implementation, this arbitrary choice appears to be the log signature seen by the witness with the lowest ID as sorted by SQL alphabetically.

This behaviour isn't wrong, but it could be surprising. We should review this code and decide if we want something more stable. Ideas are:

• whichever checkpoint the distributor saw first
• whichever checkpoint was witnessed by the witness with the smallest timestamp

Start with combine_signatures.go#Combine and trace how the first checkpoint and witness signatures are selected. Compare the proposed propagation policies, decide which behavior should be supported, and document the decision. Done means the selection rule is explicit and any resulting implementation change is covered by the project’s relevant checks.