Summary

• MemoryConnector.Close() calls ristretto.Cache.Close(), but nothing in erpc ever called Close() on a memory connector — SharedStateRegistry and EvmJsonRpcCache don't expose their own Close(), so the only lifecycle signal a connector got was its ctx being cancelled, and ristretto's own processItems/defaultPolicy background goroutines don't watch that ctx themselves. Every memory connector ever created leaked 2 goroutines for the life of the process.
• Most visible inside erpc's own erpc package test suite: each test spins up its own short-lived ERPC/network stack (and its own memory connector(s) for shared-state and/or the EVM JSON-RPC cache). Running the full package in one binary accumulated tens of thousands of live ristretto goroutines by the end of the run — enough to blow through go test's timeout on a full run of ./erpc/... (confirmed via goroutine dump: thousands of ristretto.(*Cache).processItems / defaultPolicy.processItems goroutines, all in [select], none ever collected).
• Fix: data/memory.go — tie the ristretto cache's lifetime to the connector's ctx inside NewMemoryConnector, so cache.Close() fires on context cancellation regardless of whether any caller ever reaches for MemoryConnector.Close() explicitly. Close() itself cancels a dedicated watcher context too, so callers that build a connector with a non-cancelable ctx (context.Background(), used by several call sites in this repo) and rely solely on calling Close() don't leak the watcher goroutine either.
• Concurrency safety: closing Ristretto's cache concurrently with an in-flight Set/Get/Delete is unsafe on its own (Cache.Close() closes internal channels — a racing Set() can data-race or panic with "send on closed channel"). Every cache-touching method now takes a read lock and checks a closed flag before touching the cache; Close() takes the write lock, so it can't proceed until every in-flight op has released, and no new op can start once closed. This was not theoretical — it's exactly what CI's -race run caught in architecture/svm (TestSvmStatePoller_ConcurrentSuggestionsDuringPoll_StaySlotMonotonic cancels a poller's ctx while a background goroutine is still writing a shared-state counter through the same connector).

Test plan

• TestMemoryConnector_ClosesRistrettoGoroutinesOnContextCancel / ...OnExplicitClose — create/close 20 short-lived connectors each way and assert goroutine count returns near baseline; fail on the leaking version, pass with the fix.
• TestMemoryConnector_SetRacingContextCancelDoesNotPanic — reproduces the TestSvmStatePoller_ConcurrentSuggestionsDuringPoll_StaySlotMonotonic shape (background Set() loop racing a ctx cancel) under -race; reliably data-races/panics on the intermediate sync.Once-only version, clean on the final closeMu/closed version.
• go test ./data/... -race — passes (only Docker-testcontainer-dependent tests fail locally, no Docker daemon here, unrelated).
• go test ./architecture/svm/... -race -count=2 and go test ./erpc/... -race -run 'TestSvm_' — pass on top of latest main (which now includes fix(svm): pass the miss reason, and stop counting cold reads as errors #1067's SVM miss-reason fix).
• Full go test ./erpc/...: on main before this fix, a full run of the package reliably timed out via goroutine-leak-driven slowdown; with the fix the suite progresses far further per unit time before hitting remaining, separate stdlib net/http keep-alive overhead from ~100 fixture-created HTTP servers in one binary (pre-existing test-scaffolding cost, not this leak — noted for visibility, not fixed here).

Rebased onto latest main (which now includes #1067) to drop an earlier, more superficial fix I'd made to the same SVM miss-reason bug — #1067 fixes it properly (including a second bug it uncovered) and supersedes that part of this PR entirely. This PR is now scoped purely to the Ristretto goroutine leak / concurrency fix.