Engine: park a host thread on the pump with Advanced.WaitForScheduledWork

[lahma]

PR 0 of the Web Workers plan (#3167 §3 and §14), and useful entirely on its own: the piece a host driving
one engine per thread was missing.

Engine.Advanced.TimeUntilNextScheduledWork answers when to pump, but a job that arrives from another
thread — an interop Task settling, a message posted in from a second engine, an asynchronous module load
completing — has no due time for it to report, so a dedicated pump thread could only find such work by
polling, paying up to its poll ceiling in latency on every arrival. This adds the wait that parks on it:

public bool WaitForScheduledWork(TimeSpan timeout, CancellationToken cancellationToken = default);
public Task<bool> WaitForScheduledWorkAsync(TimeSpan timeout, CancellationToken cancellationToken = default);

Contract. Returns true when there is (probably) work — call ProcessTasks() next — and false on
timeout. It does not pump: ProcessTasks stays the pump and there is still no third method that drains
for a budget. The wait is bounded internally by the engine's own next due time, so a setTimeout(f, 1)
wakes it in about a millisecond rather than at the caller's ceiling; a cross-thread EventLoop.Enqueue
wakes it immediately through the work-arrived event that already existed for the module-load drain. A
registered CancellationConstraint ends it as ExecutionCanceledException, the caller's token as
OperationCanceledException, and spurious wakes are expected and documented.

Ownership is the interesting part, and both forms follow existing discipline rather than inventing any.
The synchronous form holds EnterHostCall() for its whole duration, so one drainer per engine is
self-enforcing — a second thread gets the engine's ordinary "already in use by another thread" admission
error, and enqueueing (deliberately unguarded) still works and is what wakes it. The asynchronous form takes
the async host-operation reservation synchronously — an engine in use is refused before a Task exists,
exactly as EvaluateAsync reports it — and re-claims the resuming thread per look at the schedule, since
the timer and atomics heaps it consults are engine-thread state. Entered from inside a job, the sync form
idles out and answers false (the queue is unrunnable from there — the same rule the engine's internal
waits apply), and the async form is refused by its own reservation.

The implementation is a thin assembly over internals that all existed (EventLoop.WaitForWork /
WaitForEventAsync / TimeUntilNextPumpScheduledWork): no new Engine field, no new synchronization. All
target frameworks, no web-API flag, nothing under Jint/WebApi/. README's host-loop section now shows the
park-and-pump shape instead of telling hosts to keep a cadence of their own.

Tests: 12 across Jint.Tests (mechanism, including the ownership pin that parks a wait and proves a
guarded entry is refused for its whole duration) and Jint.Tests.PublicInterface (a cross-thread promise
settle waking a parked host, on both TFMs including net472). Every pin was verified to fail against the
mutation it names — the queue-check, the schedule clamp, the sync ownership, the async reservation and
release, the token mapping, and EventLoop.Enqueue's wake signal.

Part of #3167.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PnghUC3EKrYa12xQ2LaYyd