[manjari25]

Why?

The Tango-backed conflict analyzer compares a new batch against the signature of every in-flight batch. Reading all of those from the signature store on every analysis would be slow, especially after a restart. This PR adds the in-memory cache that sits in front of the store.

What?

Everything is added under submitqueue/extension/conflict/tango:

• Adds a byte-bounded LRU cache of TargetSignatures, keyed by queue and batch ID. One cache serves every queue, with a single memory budget, so a busy queue can use space an idle one left behind.
• A lookup refreshes an entry's recency. Adding a signature evicts the least recently used entries until the cache is back within budget. A signature larger than the whole budget is not cached, and a zero budget caches nothing.
• Entries are sized from their targets (16 bytes each) plus a fixed overhead. The figure is an estimate that keeps the budget tied to memory use.
• Signatures are immutable, so a cached value is shared with callers instead of copied. Signatures can have millions of targets, and copying them on every read would defeat the cache. Nobody may modify Targets.
• A miss costs one store read, never a call to Tango, so evicting an in-flight batch is safe. That is why there is no explicit eviction when a batch leaves the in-flight set.
• The cache is unexported and nothing uses it yet. The analyzer that uses it is a later PR in this stack.
• Tests cover hits and misses, queue, a read refreshing recency, repeated puts of one key not evicting a neighbour, an oversized signature, a zero budget, and a concurrent get and put test under -race.

Test Plan

./tool/bazel test //submitqueue/extension/conflict/tango/...
go test -race ./submitqueue/extension/conflict/tango/
make check-gazelle
make check-mocks
make lint
CI

Issue