Antispam efficiency improvements

Now that deduplication has been migrated to Tessera's deduplication, each time an index is returned, TesseraCT reads the leaf from GCS/S3 and extract the timestamp out of it and build the SCT again. We can cache this timestamp to make subsequent similar requests faster. We could also consider:

• caching the entire SCT (this would have parsing implications, as well as memory usage impact)
• caching the timestamp and the index, then disabling antispam caching on Tessera (this would cut memory usage and remove layered caches)
• caching the timestamp of all entries in the bundle from which an entry is being deduped for a given request (To get the timestamp of entry X in a bundle, all the entries with a smaller index need to be parsed first, so their timestamp would be available. This might not be a good idea depending on user query patterns though.)

Trace the TesseraCT path that handles returned indexes, reads leaves from GCS/S3, extracts timestamps, and rebuilds SCT responses. Compare the listed timestamp, SCT, and bundle-entry caching options, then validate that repeated similar requests become faster without incorrect results or unacceptable memory use.