Improve robustness when constructing SCT for duplicate entry

[AGWA]

Following up from transparency-dev/tessera#1018

I think it's fragile how tesseract overwrites just the timestamp, but otherwise keeps the entry that was constructed from the submission. It means that inputs to the critical SCT signing operation come from multiple places, and consequentially might not be coherent. Instead, tesseract should retrieve the entire entry from storage, not just the timestamp, and completely discard the entry constructed from the submission. That way, a malfunction in the antispam driver can only cause the wrong SCT to be returned; it can't kill the log by returning an invalid SCT.

[phbnf]

Good point, thank you very much for the report @AGWA. I think we should also check that all the fields returned from deduplication match with the submission, not to return any erroneous SCT.