fix(virtual-core): don't call getItemKey with a stale index in RO disconnect cleanup

Commit 843690b added an elementsCache cleanup in the ResizeObserver
disconnect path that looked up the cache key via getItemKey(index).
When items have been removed from the end of the list, that index can
be past items.length, so any user-supplied getItemKey that indexes into
the data array throws — exactly the bug PR #1148 had fixed for the
non-cleanup paths.

Fix: find the cache entry by node identity instead. Iterating
elementsCache is O(visible-window), which is fine for a path that only
fires on disconnect, and it naturally handles the React-replaced-the-
node-under-the-same-key case (the === check just won't match).

The stale-index e2e test now passes on both react-virtual and
angular-virtual, and the two RO-cleanup unit tests still pass since
they were written against node identity, not key lookup.

Author: tannerlinsley

.changeset/fix-core-elementscache-stale-index.md

@@ -0,0 +1,9 @@
+---
+'@tanstack/virtual-core': patch
+---
+
+Don't call `getItemKey` with a possibly-stale index when cleaning up
+`elementsCache` for a disconnected node. The cleanup now finds the
+matching entry by node identity, so removing items from the end of
+the list while a `ResizeObserver` still has the now-detached node
+queued no longer throws (regression of #1148).

packages/virtual-core/src/index.ts

@@ -429,13 +429,18 @@ export class Virtualizer<
 
             if (!node.isConnected) {
               this.observer.unobserve(node)
-              if (index >= 0) {
-                const key = this.options.getItemKey(index)
-                // Only delete if this node is still the cached one — guard
-                // against the case where React mounted a new node for the
-                // same key after this one disconnected.
-                if (this.elementsCache.get(key) === node) {
-                  this.elementsCache.delete(key)
+              // Find the cache entry pointing to this exact node and remove
+              // it. We can't call getItemKey(index) here because items may
+              // have been removed since this node was rendered — the index
+              // could be stale and out-of-bounds in the user's data array
+              // (regression test in e2e/.../stale-index.spec.ts, fix #1148).
+              // The === comparison naturally handles the React-replaced-
+              // a-node-for-the-same-key case: that entry now points to a
+              // different node, so this loop won't match.
+              for (const [cacheKey, cachedNode] of this.elementsCache) {
+                if (cachedNode === node) {
+                  this.elementsCache.delete(cacheKey)
+                  break
                 }
               }
               return