golang-samber-hotlisted

# samber/hot in-process caching Treat a hot cache as process-local state. Start by reading `go.mod`, the `NewHotCache` builder chain, loader implementations, invalidation sites, metrics registration, and shutdown. Verify builder and method names against the selected module version. ## Define the cache contract Record the decisions that callers can observe: - key dimensions, including tenant, identity, locale, permissions, and schema version; - value ownership and whether returned pointers may be mutated; - freshness, stale, and hard-expiry windows; - how absence differs from a loader failure; - capacity in entries and the expected memory envelope; - how writes and multi-replica deployments invalidate cached reads. ## Build with the needed features The common entry point is `hot.NewHotCache[K, V](algorithm, capacity)`, followed by builder options and `Build()`. The selected release may expose: | Concern | Representative API | | --- | --- | | Expiration | `WithTTL`, `WithJitter`, `SetWithTTL` | | Background expiry | `WithJanitor`, `StopJanitor` | | Read-through | `WithLoaders`, `GetWithLoaders`, batch variants | | Stale revalidation | `WithRevalidation`, revalidation error policy | | Negative caching | `WithMissingCache`, `WithMissingSharedCache`, `SetMissing*` | | Contention | `WithSharding` and a stable `Hasher[K]` | | Mutable values | `WithCopyOnRead`, `WithCopyOnWrite` | | Startup and telemetry | `WithWarmUp*`, `WithPrometheusMetrics` | `Get` returns a value, a foun