Deferred effect's compute sees prev=undefined on a held mount, prev=1 on a plain mount #4556

Found in review of #4547 (fixes #4543), on next at 65da5de.

Repro: an effect with defer: true whose compute reads a signal starting at 1. Mount it plainly, then write 2: compute runs as compute(2, prev=1). Mount the same component inside a held update (for example under a <Show> that a write flips while async is pending), let the hold commit, then write 2: compute runs as compute(2, prev=undefined).

Cause: #4547 makes a deferred effect drop its queued first run when a held mount commits. That also drops the staged first value, so the next compute has no prev.

Expected: the same prev in both. A held mount lands at its commit as if it had mounted then (D-13, D-3); the hold must not be visible in what user code receives afterwards.

Fix constraint: the measured fix keeps the staged value (node._pendingValue !== NOT_PENDING && (node._value = node._pendingValue) before clearing it) but costs +24 B minified on every core row, which puts hello world (compiled floor) at 9,992 B over its 9,980 B cap. We need a cheaper form, or one behind an optional engine hook.