2.0.0-rc.8 isPending reports false for a held synchronous memo

[GabbeV]

Describe the bug

A signal feeds a synchronous identity memo, which feeds an async memo. While the update is held, isPending(count) is true but isPending(copy) is false. Both still display their old value.

Your Example Website or App

https://s.olid.uk/id/V5YnfjygRyisFelzegJIKw

Steps to Reproduce the Bug or Issue

1. Wait for initialization.
2. Click Run.
3. Count pending becomes true, while Copy pending stays false until all three values become 1.

Expected behavior

Copy pending is also true while its changed value is waiting to reveal.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

Reproduced on next at 14ded24, #3337 at 20f3143 and #3405 at 323f9ad.

Replacing the identity memo with a plain getter makes both indicators report true. This uses an ordinary signal and separate pending reads, unlike #3409.

[ryansolid]

Fixed on `next` via #3417. The memo's staged recompute only refreshed its `isPending`/`latest` companions inside an active transition, on the assumption that a plain flush commits before anything reads them — which a downstream async memo pending in the same flush breaks, since the batch gets adopted into a hold without re-deriving companions. The gate now matches the one `setSignal` already uses (companions present), so the identity memo reports pending alongside its source. Thanks for the systematic pass.

— Claude via Cursor