@@ -38,15 +38,18 @@ type evictedEntry[K comparable, V any] struct {
 // Concurrent callers for the same key share the result, coalescing both
 // liveness checks and storage round-trips into a single operation per key.
 //
-// # onEvict runs off the cache lock
+// # onEvict runs without cache mutexes held by its invoking goroutine
 //
 // The user onEvict may perform slow teardown (e.g. closing network
-// connections). To keep that work off the shared cache lock, the LRU's own
-// eviction callback only *buffers* each evicted entry (bufferEvicted); every
-// mutating operation then drains the buffer and invokes the user onEvict via
-// drainEvictions after releasing mu. onEvict therefore never runs while mu is
-// held, so a slow onEvict never blocks Get/Set/Remove/RemoveMatching on other
-// keys.
+// connections). The LRU's own eviction callback only *buffers* each evicted
+// entry (bufferEvicted). drainEvictions snapshots the buffer under evictMu,
+// releases it, then invokes onEvict; direct callbacks on discarded miss-load
+// values likewise run without either cache mutex held by their invoking
+// goroutine. A drain may claim entries buffered by another operation, so a
+// slow callback can delay that drainer's return, including one for a different
+// key. Conversely, an operation can return before its own eviction callbacks
+// finish if another drainer claimed them. The invoking goroutine holds neither
+// cache mutex during callbacks, though other goroutines may hold them.
 type ValidatingCache[K comparable, V any] struct {
 	lruCache *lru.Cache[K, V]
 	flight   singleflight.Group
@@ -65,9 +68,8 @@ type ValidatingCache[K comparable, V any] struct {
 	// acquired, so it introduces no lock-ordering cycle with mu even though
 	// bufferEvicted may run while mu is held.
 	evictMu sync.Mutex
-	// pending holds entries evicted by the LRU but not yet handed to the user
-	// onEvict. Drained (and the user onEvict invoked) by drainEvictions after
-	// mu is released. Always nil when onEvict is nil.
+	// pending holds entries evicted by the LRU but not yet claimed by
+	// drainEvictions. Always nil when onEvict is nil.
 	pending []evictedEntry[K, V]
 }
 
@@ -82,9 +84,9 @@ type ValidatingCache[K comparable, V any] struct {
 // key and the cached value so callers can inspect the value without a separate
 // read. Returning ErrExpired evicts the entry; any other error is transient
 // (cached value returned unchanged). It must not be nil.
-// onEvict is called after any eviction (LRU or expiry); it may be nil. It is
-// always invoked outside the cache lock (see the type doc), so it is safe for
-// onEvict to perform slow teardown without blocking other cache operations.
+// onEvict is called after any eviction (LRU or expiry); it may be nil. Its
+// invoking goroutine holds neither cache mutex while it runs; see the type doc
+// for drain and return-time semantics.
 func New[K comparable, V any](
 	capacity int,
 	load func(context.Context, K) (V, error),
@@ -109,7 +111,8 @@ func New[K comparable, V any](
 
 	// When onEvict is nil there is nothing to defer, so the LRU gets no
 	// callback and evicted values are simply dropped. Otherwise the LRU
-	// callback only buffers; drainEvictions runs the real onEvict off the lock.
+	// callback only buffers; drainEvictions invokes the real callback without a
+	// cache mutex held by its invoking goroutine.
 	var lruEvict func(K, V)
 	if onEvict != nil {
 		lruEvict = c.bufferEvicted
@@ -124,19 +127,22 @@ func New[K comparable, V any](
 }
 
 // bufferEvicted is the LRU's eviction callback. The LRU fires it from Add/Remove
-// while the caller may still hold mu (getHit, Set, RemoveMatching), so it must
-// not run the user onEvict inline. It records the entry for drainEvictions to
-// hand to onEvict after mu is released. Only installed when onEvict is non-nil.
+// while the caller may still hold mu (getHit, Set, Remove, RemoveMatching), so it
+// must not run the user onEvict inline. It records the entry for a later
+// drainEvictions call. Only installed when onEvict is non-nil.
 func (c *ValidatingCache[K, V]) bufferEvicted(key K, val V) {
 	c.evictMu.Lock()
 	c.pending = append(c.pending, evictedEntry[K, V]{key: key, val: val})
 	c.evictMu.Unlock()
 }
 
-// drainEvictions invokes the user onEvict for every entry buffered since the
-// last drain. Callers MUST NOT hold mu, so onEvict runs off the cache lock. It
-// is safe to call when onEvict is nil (nothing is ever buffered) and when there
-// is nothing pending.
+// drainEvictions invokes the user onEvict for every entry it claims from the
+// buffer. It snapshots and clears pending while holding evictMu, then releases
+// it before invoking callbacks; callers MUST NOT hold mu. Another drain may
+// claim entries buffered by this operation, so this call may process entries
+// buffered by another operation. See the type doc for the cache-lock invariant.
+// It is safe to call when onEvict is nil (nothing is ever buffered) and when
+// there is nothing pending.
 func (c *ValidatingCache[K, V]) drainEvictions() {
 	if c.onEvict == nil {
 		return
@@ -153,8 +159,8 @@ func (c *ValidatingCache[K, V]) drainEvictions() {
 
 // getHit validates a known-present cache entry and returns its value.
 // If the entry has definitively expired it is removed (its eviction buffered
-// for the caller to drain) and (zero, false) is returned. Transient check
-// errors leave the entry in place and return the cached value.
+// for a later drain) and (zero, false) is returned. Transient check errors
+// leave the entry in place and return the cached value.
 func (c *ValidatingCache[K, V]) getHit(ctx context.Context, key K, val V) (V, bool) {
 	if err := c.check(ctx, key, val); err != nil {
 		if errors.Is(err, ErrExpired) {
@@ -164,7 +170,7 @@ func (c *ValidatingCache[K, V]) getHit(ctx context.Context, key K, val V) (V, bo
 			// freshly-written value that the caller intended to keep.
 			c.mu.Lock()
 			if current, ok := c.lruCache.Peek(key); ok && sameEntry(current, val) {
-				// Remove buffers the eviction; Get drains it after mu is released.
+				// Remove buffers the eviction; Get drains after getHit releases mu.
 				c.lruCache.Remove(key)
 			}
 			c.mu.Unlock()
@@ -221,7 +227,7 @@ func (c *ValidatingCache[K, V]) Get(ctx context.Context, key K) (V, bool) {
 			if winner, ok := c.lruCache.Get(key); ok {
 				// Winner confirmed: v is definitively discarded — release its
 				// resources. v was never stored, so it is not buffered; invoke
-				// onEvict directly (this runs outside mu, so it is off the lock).
+				// onEvict directly; the invoking goroutine holds no cache mutex.
 				if c.onEvict != nil {
 					c.onEvict(key, v)
 				}
@@ -235,9 +241,10 @@ func (c *ValidatingCache[K, V]) Get(ctx context.Context, key K) (V, bool) {
 		return result{v: v}, nil
 	})
 	// Drain any evictions buffered by getHit's Remove or the miss path's
-	// ContainsOrAdd/Add (LRU capacity eviction). mu is not held here, so onEvict
-	// runs off the lock. Coalesced singleflight waiters also drain; a drain that
-	// finds nothing pending is a cheap no-op.
+	// ContainsOrAdd/Add (LRU capacity eviction). The invoking goroutine holds no
+	// cache mutex while drainEvictions runs; see the type doc. Coalesced
+	// singleflight waiters also drain; a drain that finds nothing pending is a
+	// cheap no-op.
 	c.drainEvictions()
 	if err != nil {
 		var zero V
@@ -248,9 +255,9 @@ func (c *ValidatingCache[K, V]) Get(ctx context.Context, key K) (V, bool) {
 }
 
 // Set stores value under key, moving the entry to the MRU position. If the
-// cache is at capacity, the least-recently-used entry is evicted first and
-// onEvict is called for it — after mu is released, so a slow onEvict does not
-// block concurrent cache operations.
+// cache is at capacity, the least-recently-used entry is evicted first and its
+// callback is drained without a cache mutex held by this goroutine; see the
+// type doc for return-time semantics.
 func (c *ValidatingCache[K, V]) Set(key K, value V) {
 	c.mu.Lock()
 	c.lruCache.Add(key, value)
@@ -265,10 +272,9 @@ func (c *ValidatingCache[K, V]) Len() int {
 
 // Remove deletes the entry for key and reports whether one was present.
 //
-// It mirrors RemoveMatching's lock discipline: the removal runs under mu (which
-// buffers the eviction via bufferEvicted) and the user onEvict runs in
-// drainEvictions after mu is released, so a slow teardown never blocks
-// Get/Set/Remove/RemoveMatching on other keys.
+// It mirrors RemoveMatching's lock discipline: removal runs under mu and
+// buffers the eviction; drainEvictions runs after this goroutine releases mu.
+// The callback and return-time semantics are described in the type doc.
 //
 // Removing an absent key is a no-op returning false, so callers on a
 // termination path may invoke it unconditionally without first probing the
@@ -278,7 +284,7 @@ func (c *ValidatingCache[K, V]) Remove(key K) bool {
 	removed := c.lruCache.Remove(key) // buffers the eviction; drained below
 	c.mu.Unlock()
 
-	// Run onEvict off the lock, matching RemoveMatching.
+	// Invoke callbacks after this goroutine releases mu; see the type doc.
 	c.drainEvictions()
 	return removed
 }
@@ -287,12 +293,11 @@ func (c *ValidatingCache[K, V]) Remove(key K) bool {
 // user onEvict for each removed entry, and returns the number removed.
 //
 // pred runs under the cache lock (the same lock Set contends for) and must not
-// call back into the cache. onEvict, however, runs via drainEvictions after all
-// removals complete and the lock is released, so a slow onEvict (e.g. closing a
-// hung backend connection) delays only the drain, never the shared cache lock:
-// a concurrent Set/Get on any key proceeds while a slow teardown is in flight.
-// This is intended for infrequent bulk eviction (e.g. reconciling sessions
-// after a backend is removed from the registry), not a hot path.
+// call back into the cache. This operation calls drainEvictions after removals
+// complete and this goroutine releases mu. Another drainer may invoke callbacks
+// earlier. See the type doc for callback and return-time semantics. This is
+// intended for infrequent bulk eviction (e.g. reconciling sessions after a
+// backend is removed from the registry), not a hot path.
 func (c *ValidatingCache[K, V]) RemoveMatching(pred func(K, V) bool) int {
 	// Snapshot the candidate keys under a short lock. Keys() returns a copy and
 	// Peek does not update recency, so evaluating pred here leaves the LRU order
@@ -318,8 +323,7 @@ func (c *ValidatingCache[K, V]) RemoveMatching(pred func(K, V) bool) int {
 		}
 		c.mu.Unlock()
 	}
-	// Run onEvict for the removed entries off the lock, so a slow teardown of one
-	// session never blocks Get/Set for the rest of the node.
+	// Invoke callbacks after this goroutine releases mu; see the type doc.
 	c.drainEvictions()
 	return removed
 }
 
@@ -500,16 +500,17 @@ func (sm *Manager) Validate(sessionID string) (isTerminated bool, err error) {
 // sessions with open backend connections:
 //
 //   - MultiSession (Phase 2): the storage key is deleted and the node-local
-//     cache entry is removed, which runs onEvict and closes the session's
-//     backend connections immediately. Storage is deleted first so that a
-//     loadSession whose metadata Update runs after the delete is rejected by
-//     the pre-existing SET XX guard; the residual race between that Update
-//     succeeding and the cache insertion is out of scope here. After deletion
-//     Validate() reports the absent key as (isTerminated=true, nil), so the
-//     next request — on this or any other replica — is rejected with a
-//     definitive 404 and the client re-initializes instead of retrying the dead
-//     session. Other replicas still self-heal through checkSession on their
-//     next cache access.
+//     cache entry is removed, eagerly scheduling onEvict to close the session's
+//     backend connections. Storage is deleted first so that a loadSession whose
+//     metadata Update runs after the delete is rejected by the pre-existing SET
+//     XX guard; the residual race between that Update succeeding and the cache
+//     insertion is out of scope here. Removal drains evictions, but a concurrent
+//     operation may claim the callback, so Terminate can return before Close
+//     finishes. After deletion Validate() reports the absent key as
+//     (isTerminated=true, nil), so the next request — on this or any other
+//     replica — is rejected with a definitive 404 and the client re-initializes
+//     instead of retrying the dead session. Other replicas still self-heal
+//     through checkSession on their next cache access.
 //
 //   - Placeholder (Phase 1): the session is marked terminated=true and left
 //     for TTL cleanup. This prevents CreateSession() from opening backend
@@ -539,8 +540,10 @@ func (sm *Manager) Terminate(sessionID string) (isNotAllowed bool, err error) {
 	}
 
 	if _, isFullSession := metadata[sessiontypes.MetadataKeyIdentityBinding]; isFullSession {
-		// Phase 2 (full MultiSession): delete from storage, then drop the
-		// node-local cache entry so its backend connections are closed now.
+		// Phase 2 (full MultiSession): delete from storage, then remove the
+		// node-local cache entry to eagerly schedule backend cleanup. A
+		// concurrent eviction drain can claim onEvict, so Terminate need not
+		// wait for Close to finish.
 		//
 		// Order matters. Deleting the storage record first means a loadSession
 		// whose metadata Update runs after this delete is rejected by the
 
@@ -604,9 +604,9 @@ func TestSessionManager_Terminate(t *testing.T) {
 	t.Run("closes MultiSession backend connections", func(t *testing.T) {
 		t.Parallel()
 
-		// After Terminate deletes the session from storage, the next GetMultiSession
-		// call triggers checkSession → ErrExpired → onEvict → Close(). This verifies
-		// that backend connections are eventually closed via lazy eviction.
+		// Terminate eagerly removes the cache entry and, in this serial test,
+		// onEvict closes its backend connections before Terminate returns. The
+		// subsequent GetMultiSession verifies the terminated session is unretrievable.
 		tools := []vmcp.Tool{{Name: "t1", Description: "tool 1"}}
 		ctrl := gomock.NewController(t)
 
@@ -632,8 +632,7 @@ func TestSessionManager_Terminate(t *testing.T) {
 				createdSess.EXPECT().BackendSessions().Return(nil).AnyTimes()
 				createdSess.EXPECT().GetRoutingTable().Return(nil).AnyTimes()
 				createdSess.EXPECT().Prompts().Return(nil).AnyTimes()
-				// Close() is called by onEvict when checkSession detects the session
-				// is gone from storage on the next GetMultiSession call.
+				// Close() is called by onEvict when Terminate removes the cache entry.
 				createdSess.EXPECT().Close().Return(nil).Times(1)
 				return createdSess, nil
 			}).Times(1)
@@ -648,18 +647,17 @@ func TestSessionManager_Terminate(t *testing.T) {
 		require.NoError(t, err)
 		require.NotNil(t, createdSess)
 
-		// CreateSession already persists tokenHashMeta via sess.GetMetadata(),
+		// CreateSession already persists bindingMeta via sess.GetMetadata(),
 		// so Terminate will take the Phase 2 path (storage.Delete) without
 		// any additional seeding.
 
-		// Terminate deletes from storage; the cache entry is evicted lazily on
-		// the next GetMultiSession call when checkSession detects ErrSessionNotFound.
+		// Terminate deletes from storage and eagerly removes the cache entry,
+		// invoking onEvict and Close() in this serial test.
 		isNotAllowed, err := sm.Terminate(sessionID)
 		require.NoError(t, err)
 		assert.False(t, isNotAllowed)
 
-		// The next GetMultiSession triggers checkSession: storage returns
-		// ErrSessionNotFound → ErrExpired → onEvict → Close().
+		// The subsequent GetMultiSession verifies the deleted session is not returned.
 		_, ok := sm.GetMultiSession(t.Context(), sessionID)
 		assert.False(t, ok, "terminated session must not be returned")
 		// gomock verifies Close() was called exactly once via Times(1)