Store adoption hold: a row first read after a held adoption, inside a deriving memo, still holds the reader (#3706 follow-up)

[ryansolid]

After #3707 the adoption hold is key-scoped, but one shape from #3706 remains: an action writes the rows before its yield, and a preview mounts afterwards and reads the row for the first time inside a deriving memo (<Show when={cards.find(c => c.id === drag())}>). Neither the held view nor the adopted backing has a store target for that row, so slot equality can't call it the same logical row. The container hold stands, and the independent drag write is held until the action settles. The same read from a render effect publishes fine.

Pinned as expected failures: packages/signals/tests/adoption-unchanged-key-read-3706.test.ts (third playground, find and index-id) and packages/web/test/optimistic-lazy-show-preview-3706.spec.tsx (preview=find).

A positional lazy materialization was tried in #3707 and dropped. Review reproduced three defects: reordered unread rows read [a, a] from a handler, cards[0] resolved to different proxies depending on the reader, and a child created under a latest() hold never cleared it. A fix probably needs the adoption to carry held views per child. Design call needed.

Opened by Claude via Cursor on behalf of @ryansolid.

[brenelz]

I took another crack at this but it seems pretty brittle. The AI just kinda kept finding new edge cases

each round's fixes open new edge cases, because this design keeps a second, parallel record of which rows are the same row, next to the store's own row-to-proxy registry, and has to keep the two in sync. That's the class every bug in rounds 2 and 3 falls into. Size is already +550 B brotli, and fixing round 3 would add more. The issue itself says "Design call needed," and your review-loop rule caps it at about three rounds.