driver: an export call is not done while any activation is hop-parked (#280)

[lannbot]

The export driver's exit predicate (resolvedSeen && !midWasmCall())
scoped its mid-wasm-call test to the export's OWN task. When a background
task's async host import settled on a microtask while another export
call's driver was live, that driver's tick resumed the background
task's callback activation — a promising entry, hop-parked in
store.awaiting with no SuspensionPoint owner — and then declared itself
done. Nobody owned the hop: the settlement pump arms only on outstanding
real host calls, and the one that caused the resumption had already
settled. The activation sat unserviced until an unrelated later call
drove the store (or forever). A settle one macrotask later dodged it only
because no driver was live at settle time and the pump owned it.

A hop is something the driver itself put in flight and that lands within
a microtask on the engine's own schedule; the driver that caused it must
see it land. The predicate now also requires no hop-parked thread of ANY
task store-wide, via entryHopThreads generalized to an optional
instance filter. midWasmCall stays for the export task's own genuinely
JSPI-suspended thread, which the hop test deliberately excludes.

Repro pinned in e2e_cancel_import_test.ts: the cancel-import guest's
detached task parked on a hand-held promise, resolved synchronously as a
second export call's driver starts; pre-fix the driver exits with
awaiting=1 hostCalls=0 (the issue's #25 EXIT-done trace verbatim).

Closes #280.

Gates run locally: check, test-runtime, conformance, sched-seeds, smoke-c0, smoke-tls, test-ct-runner, test-bundle.

Automerge armed. The await macrotask() workaround in polyengine-dioxus host/src/eval.ts can be removed once this ships.