[GR-75575] Check for invalid IsolateThread in AbstractStackFrameSpliterator.

[graalvmbot]

Problem to be fixed
ContinuationSpliterator could keep using a stack-allocated JavaStackWalk pointer after virtual-thread carrier migration, causing writes into the old carrier thread’s stack.

implemented fix and AI review
For the specific bug described in GR-75575, the fix is complete.

The vulnerable condition is: a heap object (ContinuationSpliterator) keeps a pointer to stack-allocated state (JavaStackWalk walk), and later uses it after execution has moved to another carrier/isolate thread. The only safe invariant is “this spliterator may only be advanced by the isolate thread that created it.”

That is exactly what the patch enforces:

• ContinuationSpliterator captures CurrentIsolate.getCurrentThread() at construction.
• Every stream pull enters tryAdvance(), which calls checkState() before advancePhysically().
• advancePhysically() is the only path to initializeForContinuation(), updateStackPointerForContinuation(), and advanceForContinuation().
• So a migrated/cross-thread pull fails before any stale stack pointer write can happen.

Why it feels small: StackFrameSpliterator already had the same guard. The bug is not a deep algorithmic flaw in continuation walking; it is an asymmetry between the current-stack and stored-continuation spliterator implementations.

Champion Reviewer
@"peter.hofer@oracle.com"