Optimistic guess tears when a memo sits between the keyed list and its binding #4561

Follow-up to #4536. #4558 fixes the shared-effect and split-bindings shapes but not this one.

Repro: take #4536's setup with split bindings: one render effect reads filter(), and a second render effect reads createMemo(() => issues.map(...)) instead of the list directly. Change the filter (open → closed) and, while that query is in flight, call the optimistic closeOne(1).

Observed (on #4558's branch): at the guess, the screen shows closed: [#3][#4] both with and without <Loading on>. That's the new question beside the old answer's rows. On next the same is inferred (not yet measured): stands serves an unlinked memo the guess there too.

Expected: open: [#3][#4] (without on) or loading (with on). The frame stays whole (F-1, D-34 ¶3).

Cause: the #4558 fix keeps only render effects observing the in-flight question. The memo is unlinked and isn't a render effect, so it gets the guess, stops waiting on the flight, and the binding follows it out of the hold. Holding the memo with a link plus a stale-reader mark kept it pending and broke #4525's <For> spec (open: [#1][#3][#4] instead of the guess), so the fix has to keep the guess visible to <For> while the memo stays in the frame's hold.