Adopt resolve-with-thenable on the event loop (fix async-ordering flake)

[nickna]

Background

Follow-up to the interpreted-Test262 flake investigation. After PR #982 removed the orphan-thread amplifier, I profiled the residual flake: the suite is fast (11,303/11,385 tests <50ms, 0 genuine timeouts in isolation), and worker oversubscription alone never reproduces a flip — but under genuine full-machine CPU saturation (a 12-core burner), one test reproducibly flipped: Promise/resolve-thenable-deferred.js (Fail→Pass). A Fail→Pass flip hard-fails the baseline gate ("new pass"), so this async-ordering non-determinism — not timeouts — is the residual run-to-run flake.

Root cause

Resolving a promise with another promise — resolve(thenable), or await of a promise that was resolved with a promise — adopted the inner promise via innerTask.ContinueWith(..., TaskScheduler.Default) (SharpTSPromiseClass.RunExecutor and Interpreter.AdoptThenable). That's a thread-pool hop: it settles the outer promise off the event-loop thread with nothing on the callback queue. When the inner promise is already settled (the "deferred" case: a pending promise resolved with an already-resolved one), the event loop can observe !HasActiveHandles && _callbackQueue.Count == 0 and exit before the adoption settles, so the outer promise's .then reaction never runs. Whether the loop wins that race depends on scheduling, so the test flips Pass/Fail under load.

(The CLI happened to win the race consistently; the Test262 runner — which runs each test on a dedicated thread — lost it in isolation, which is why the test was "pinned Fail.")

Fix (interpreter-only)

Route the adoption through the event loop via a new Interpreter.AdoptInnerPromise: deliver the settle as an event-loop callback using TaskContinuationOptions.ExecuteSynchronously. So:

• an already-settled inner enqueues the settle callback inline (during resolve, before the loop starts) → the loop never starts idle → deterministic;
• a never-settling inner enqueues nothing → the loop exits normally, matching Node (a pending adoption does not by itself keep the program alive);
• the settle always runs on the event-loop thread, and completing the outer promise synchronously posts its .then continuations back onto the loop.

Used by both the new Promise executor resolve and the await-thenable path. SettleFromTask (subclass capability adoption) already used ExecuteSynchronously and is unchanged.

Validation

• Promise/resolve-thenable-deferred.js: Fail → Pass, deterministic with and under the 12-core burner (the condition that originally flipped it). Test262 interpreted baseline: +1, 0 regressions.
• Full xUnit suite 14412 / 0.
• 2 new interpreter-only regression tests (PromiseMethodTests.ResolveWithThenable_*).

Notes

• Interpreter-only. Compiled mode emits its own event loop and exhibits the same resolve-with-thenable gap (the new tests fail there) — a separate fix; the regression tests are scoped to the interpreter accordingly.
• Independent of PR Getter-aware iterator reads, IteratorClose, and timeout-safe iteration (interpreter) #982 (different files); based on main.