flake: rust/endo execute.rs XS tests intermittently fail under parallel cargo test (shared-cluster concurrency)

[kriscendobot]

While stress-running cargo test -p endo (147 tests, default parallel harness) on the CAS-registry stack tip (c0482e3fc, unmodified — verified via git stash before re-running), execute.rs XS-execution tests intermittently panic:

• ~1 in 3 full-suite runs fails, and the failing test differs run to run: observed dot_edge_prefers_exports_over_main, nested_module_relative_imports_resolve_against_referrer, require_only_exports_resolve_on_second_pass, executes_cjs_require_graph_in_xs (the last from feat(endor): full CommonJS require linkage in the archive loader #816, but the flake reproduces without that change — 2 of 5 stress runs on bare c0482e3fc).
• Each failing test passes reliably in isolation (cargo test -p endo <name> — 5/5).
• The panic is the test's .unwrap()/.expect() on xsnap::run_xs_archive_loaded, i.e. the run itself errored, not an assertion mismatch.

All these tests create XS machines through ensure_shared_cluster() concurrently, which points at a concurrency hazard in the shared cluster (or machine creation/teardown) when many XS machines run at once. Until it's found, any red cargo test -p endo needs a rerun to distinguish a real regression from this flake — worth fixing on the "a failing check is a defect in our automation" principle, and a prerequisite for putting rust/endo into CI at all.

Reproduce (observed on Linux, debug profile):

cd rust/endo
for i in 1 2 3 4 5; do cargo test -p endo execute:: 2>&1 | grep -E "test result|panicked"; done

Found while pressing #816 (npm-CAS-registry arc).