signals: a chain's verdict flips to false mid-hold where a diamond's stays true (graph shape is observable) #4562

What happens

The same reads produce different frames depending on whether the derivation is a chain or a diamond. During a held action, a chain's isPending drops to false while the hold is still open. A diamond's stays true until the commit. Graph shape shouldn't be observable.

Found while reviewing #4560. It reproduces the same way on next (404d06a) and on #4560, so it isn't caused by that PR.

Repro

const [s, setS] = createSignal(0);
const A = createMemo(async () => {
  const v = s();
  await Promise.resolve();
  if (v === 2) throw new Error("boomA");
  return v;
});
const B = createMemo(() => A() + 1);
// chain:   C = B + 2;  D = C
// diamond: C = A + 2;  D = B + C
const view = createErrorBoundary(() => `${isPending(D)}:` + D(), e => `E:${e().message}`);
createRenderEffect(view, v => log.push(v));

Steps:

1. Let the first load settle.
2. setS(1); flush().
3. Run action(function* () { setS(2); yield new Promise(r => (release = r)); })() and let it tick.
4. Call release() and let it tick twice.
5. setS(3); flush(), then let it tick.

The diamond's frames are pinned in packages/signals/tests/settle-diamond-revisit.test.ts (#4560).

The frames

1. false:3: the first load committed (A = 0).
2. true:3: s = 1 is a new question. A's flight is out, D's dependents are pending, and the screen keeps 3.
3. The action's setS(2) re-asks A inside a hold, superseding the s = 1 flight. That flight throws boomA, and the error is staged in the hold (D-41). The hold stays open until release().
4. Chain only, false:3: while the hold is still open, the view re-runs and reads isPending(D) === false with the committed 3. The diamond emits nothing here.
5. E:boomA: the commit publishes the staged error.
6. false:6 / false:9: s = 3 lands.

Ruling: the chain is wrong (F-9, with F-2)

• F-9. isPending(x) is true "iff x's value is not the final answer to a new question: an input changed and the new answer has not been committed, a landed answer waits in a hold…". At frame 4 the input has changed (s is 1, then 2 in the hold), no new answer has been committed, and the staged answer is still waiting in the hold. Nothing has answered the s = 1 question; the hold superseded it. So isPending(D) must stay true until the commit, which is what the diamond shows.
• F-2. "A change that needs async to be shown is held; the screen keeps what it showed." The screen showed true:3. Flipping it to false:3 mid-hold changes what is shown before the commit, with no commit behind the change.

So the expected chain frames are false:3, true:3, E:boomA, false:6.

Where to look

The difference lives in settlePendingSource (packages/signals/src/core/async.ts).

When the superseded flight's source settles, the walk retires D's pending state through the branch that carried it. In the diamond, D is reached a second time through the other branch. That second arrival takes the walk's early-return path, which re-runs a verdict reader or marks a staged error (stageMark), and that keeps D's verdict tied to the staged frame. In the chain there is only one arrival, so nothing re-marks D, and the view re-derives isPending(D) as settled while the hold is still open.

A likely fix is for the chain's single arrival to do what the diamond's second arrival does: a node that inherits the staged error, or whose verdict reads the hold, keeps that mark rather than reading as settled. Pin the chain frames above alongside the diamond pin.

Not fixed in #4560 on purpose: that PR keeps next's behaviour exactly.