instanceof against a ClassExprFresh parent resolves by shared class id, so an earlier evaluation's class can fail instanceof after a later evaluation #10624

Found while fixing #10455 (PR #10622), which gives an exported class factory a genuinely fresh class object per
evaluation (ClassExprFresh). Deliberately excluded from that PR's test because it is a different root cause.

Shape: an instance built from an earlier evaluation of an exported factory, constructed after a later
evaluation of the same factory has run, constructs with the correct parent but can then fail a subsequent
instanceof check against its own parent.

It looks like the instanceof class-chain walk resolves a dynamic parent by shared class id rather than per
ClassExprFresh instance, so the later evaluation's id shadows the earlier one.

Likely related to the in-flight class-chain-walk work in PR #10592 (instanceof per receiver value kind) and
PR #10614 (native-base subclass prototype identity) — whoever picks this up should read both first, since the
mechanism they touch is the one that appears to be at fault.

Repro shape (from the #10455 work): evaluate the exported factory twice, keep an instance from evaluation 1,
evaluate again, then re-construct from the evaluation-1 class and check instanceof against its parent.