cache: replace read/dirty with a concurrent hash-trie

[twmb]

Summary

Replaces the read/dirty/promote backing of cache.Cache with a concurrent
hash-trie modeled on Go's internal/sync.HashTrieMap, implemented entirely in
userspace (hash/maphash + unsafe.Sizeof(uintptr(0)); no internal/abi or
internal/goarch). Public API is unchanged; all documented semantics are
preserved, with two minor behavior shifts noted below.

Why

• The read/dirty design amortizes a write-map promotion across operations; the
  per-op cost is decent on average but adversarial workloads pay heavily for
  the copy. The trie spreads cost across per-bucket locks and eliminates the
  promotion cycle.
• Upstream sync.Map moved to a hash trie in Go 1.24, so the old inspiration
  in this package's docs was stale.
• Singleflight, stale values, TTLs, idle-age, and error caching all live above
  the storage layer and carry over unchanged.

Changes, by commit

1. bump to go 1.24, fix stale-at-epoch, tighten Clean — baseline cleanup.
   Go modules had claimed 1.18 but the code required 1.19+ (atomic.Pointer[T],
   atomic.Int64, atomic.Uint32). newStale was producing a stale born at
   the Unix epoch when the main entry's expiry was <= 0 — now bases on
   now(). Clean now calls e.del() directly instead of c.Delete(k) since
   c.each has already promoted.
2. expand test suite; fix data race in Get's post-miss return — gets coverage
   to 100% at the baseline. The new race-targeted tests caught a real data
   race: Cache.Get read l.v without any happens-before edge when a
   concurrent Swap had replaced e.p with its own loading. Fix: l.wg.Wait()
   before reading l.v to synchronize with whoever called wg.Done — either
   setve or Swap's defer.
3. add concurrent hash-trie in isolation — new cache/trie.go + unit tests.
   Standalone, not yet wired into Cache.
4. back Cache with the hash-trie; retire read/dirty machinery — Cache
   holds a trie[K, loading[V]] instead of r/mu/dirty/misses/pd. An
   ent[K, V] type alias (Go 1.24 generic aliases) names the trie's concrete
   entry type. Entry operations (entGet, entTryGet, entDel, entLoad,
   entMaybeNewStale) are free functions over that alias. Delete physically
   removes via deleteEntryIf with a "still tombstoned under lock" predicate
   to avoid clobbering a concurrent Swap resurrection; keys become eligible
   for GC promptly (TestIssue40999 still passes).
5. README: rewrite for the trie-backed cache — new design blurb, fresh
   benchmark numbers.
6. port the stdlib sync.Map tests we were missing — TestConcurrentClear,
   TestMapClearOneAllocation, TestMapRangeNoAllocations, BenchmarkClear.

Semantic shifts

Both acceptable in my read, but flagging explicitly:

• Range loses its promote-snapshot flavor. Previously each promoted
  under c.mu, so Range iterated a fixed snapshot. Now Range is a lock-free
  walk over atomic pointers; concurrent mutations may or may not be visible.
  This is the same guarantee sync.Map.Range documents and the existing
  docstring already uses that wording.
• Clean no longer serializes on c.mu. Iteration is lock-free; per-key
  physical removal takes only the trie's bucket lock. Faster, but callers who
  relied on Clean holding a global lock should know.

Benchmarks

Apple M1, Go 1.26, -count=5 -benchtime=1s, benchstat comparing the
pre-trie baseline to the current branch.

Time per op — geomean -35.24%.

Largest wins:

Benchmark	Pre-trie	Trie	Δ
AdversarialAlloc	350.8 ns	11.4 ns	-96.74%
AdversarialDelete	132.2 ns	6.5 ns	-95.10%
SwapMostlyMisses	1032 ns	154 ns	-85.11%
LoadOrStoreUnique	1449 ns	592 ns	-59.17%
LoadAndDeleteBalanced	10.7 ns	4.4 ns	-58.66%
LoadAndDeleteUnique	4.3 ns	1.8 ns	-58.59%
LoadOrStoreBalanced	702 ns	318 ns	-54.77%
CompareAndDeleteMostlyHits	131 ns	91 ns	-30.63%
DeleteCollision	5.1 ns	3.6 ns	-29.23%
SwapCollision	338 ns	242 ns	-28.47%
CompareAndSwapNoExistingKey	2.5 ns	1.9 ns	-22.97%

Regressions:

Benchmark	Pre-trie	Trie	Δ
LoadAndDeleteCollision	7.1 ns	67.6 ns	+853.35%
CompareAndSwapCollision	10.1 ns	17.6 ns	+73.45%
LoadMostlyMisses	3.4 ns	4.6 ns	+33.40%

The *Collision regressions are intrinsic: the trie physically removes on
Delete (required to keep keys GC-eligible per TestIssue40999) so every
Delete takes the bucket lock. Pre-trie just did a single CAS to nil and
deferred physical removal to the promotion cycle. When many goroutines hammer
the same key, they all serialize on that bucket mutex. LoadMostlyMisses
pays a small fixed cost for the hash-walk on every miss.

Allocations. AdversarialAlloc and AdversarialDelete drop to 0 B/op
(pre-trie was 55 and 36, respectively — the cost of dirty-map promotion
copying). SwapMostlyMisses drops from 4 allocs/op to 2. Per-op allocations
on the insert/swap paths (LoadOrStore*, Swap*Hits, CompareAndSwap*Hits)
are intrinsic: each operation may install a fresh loading[V] carrying the
singleflight machinery (Mutex, WaitGroup, atomic counters) that a plain
sync.Map does not need.

Test plan

• Verify go test ./... -race -count=3 on the CI environment.
• Confirm the two semantic shifts (Range snapshot-less, Clean
  concurrency) don't affect any downstream consumers.
• Spot-check the benchmark regressions against real workloads — the
  LoadAndDeleteCollision shape is narrow (single hot key being
  repeatedly add/removed) but worth checking if anyone depends on it.