rc.9: overlapping optimistic moves duplicate an item across filtered keyed lists

Describe the bug

A createOptimisticStore backed by an async iterable becomes inconsistent with filtered, keyed For lists while actions overlap. After an older action is confirmed, a later update causes the same item to render in two lists, even though the optimistic store contains that item only once and assigns it to only one list.

The reduced case has two cards and four optimistic moves. No router, SSR, database, drag handling, effects, or application-managed ownership.

Your Example Website or App

https://s.olid.uk/id/kln8x1FLT-GushIouj37EQ

Steps to Reproduce the Bug or Issue

Click Run reproduction once. Reload to repeat.

The button:

1. Moves card 0 to lane 1, order 1.
2. Moves card 0 to lane 2, order 6.
3. Moves card 1 to lane 1, order 9.
4. Publishes the authoritative result of action 1, resolves only action 1, and allows a task turn.
5. Moves card 1 within lane 1, order 3.

Actions 2-4 remain pending. Each move calls public flush().

Observed: lane 1 renders cards 0 and 1; lane 2 also renders card 0. The store contains only two cards and places card 0 only in lane 2.

Expected behavior

Lane 1 should contain only card 1; lane 2 should contain only card 0. Confirming an older move must not expose its old placement alongside the newer optimistic placement.

Screenshots or Videos

No response

Platform

Linux/WSL, Chromium.
Published solid-js, @solidjs/signals, @solidjs/web and native @solidjs/compiler 2.0.0-rc.9.
Also reproduces with matching pkg.pr.new/mizulu/solid2 runtime packages at 788277a, retaining the rc.9 native compiler.
Verified in development and production DOM builds.

Additional context

Control: omit only publish(source), leaving action resolution and all moves unchanged. No duplicate appears.

In the full app, rendering recovers after all requests are confirmed. This reports inconsistent pending rendering, not persisted duplicate records.

Related: #3543. Preview 788277a fixes that subscriber-leak repro, but this duplication still reproduces. The exact internal cause has not been identified.

Start by running the linked reproduction and inspect createOptimisticStore with filtered, keyed For lists. Trace how public flush(), publish(source), and overlapping action resolution update pending placements after the older action is confirmed. Done means the reproduction keeps card 0 only in lane 2 and card 1 only in lane 1 while actions 2–4 remain pending.