Bump emsdk 4.0.19 -> 5.0.7 (fixes the wasm worker hang)

[Fedr]

Why

emscripten's emscripten_proxy_finish signalled the proxy context's condition variable after
releasing its mutex:

pthread_mutex_lock(&ctx->sync.mutex);
ctx->sync.state = DONE;
remove_active_ctx(ctx);
pthread_mutex_unlock(&ctx->sync.mutex);
/* preempted here */
pthread_cond_signal(&ctx->sync.cond);

In that window the waiting thread takes the mutex, sees DONE, skips pthread_cond_wait, returns
and destroys the context — which lives on its own stack. The finishing thread then signals a condvar
that is gone, and the thread that should have woken waits forever.

Under -pthread emscripten proxies every syscall synchronously to the main thread, so any
worker doing file I/O could hit it. That is the wasm STEP-import CI stall, and it explains why the
hang moved between unzip, std::filesystem::copy, compressZip and the scene load — the stage was
never the point.

Upstream fix: emscripten-core/emscripten#26582, merged 2026-04-01, shipped in emsdk 5.0.5. We
pin 4.0.19, which predates it.

Measured with a standalone reproducer (two threads doing MEMFS I/O, main thread in a normal event
loop, no MeshLib) at https://github.com/MeshInspector/wasm-memfs-stall — stalls per 480 s shard, 24
shards per cell:

emsdk	4.0.19	4.0.23	5.0.0	5.0.4	5.0.5	5.0.7	6.0.0	6.0.9
stalls	~15%	3	5	3	0	0	0	0 (72 shards)

Zero in 144 shards from 5.0.5 up, against roughly one shard in seven below it.

Why 5.0.7 and not 6.0.9

6.0.9 was the first target, and it kept uncovering work rather than being a bump: PIC needed across
all thirdparty, then emsdk's own zlib port is not PIC either and is not ours to rebuild, then fmt
stopped compiling because clang 24 no longer pulls <cstdlib> in transitively. 5.0.7 is the last of
the 5.x line, carries the fix, and is LLVM 23 rather than 24. Moving to 6.x is worth doing on its
own schedule.

What changed here

• emscripten/emsdk:4.0.19-arm64 → 5.0.7-arm64, and EMSDK_VERSION with it.
• Base stage ubuntu:22.04 → ubuntu:24.04, and the apt suites jammy → noble, for the same
  glibc reason.
• CMAKE_POSITION_INDEPENDENT_CODE=ON in the emscripten branch of build_thirdparty.sh. Several
  thirdparty libs are built shared here and link others statically; a wasm .so is a side module,
  so wasm-ld wants every object in it PIC. 4.0.19 tolerated non-PIC archives — libzip.so against
  libmbedcrypto.a, and libjpeg-turbo's sharedlib/ examples — and the newer toolchain does not.
  Every thirdparty script inherits MR_CMAKE_OPTIONS, so it is set once rather than per library,
  and only on the emscripten path.

Deliberately not touched

docker/emscripten-generate-c-bindingsDockerfile and the 4.0.19-arm64 row of
.github/workflows/matrix/docker-images-emscripten-c-bindings.json stay put. That matrix is
intentionally multi-version (it still carries 3.1.38), those images generate bindings rather than
build the shipped wasm, and moving the arm64 row to a noble base additionally needs
VERSION_CODENAME plumbed through as a build-arg in prepare-images.yml. Happy to fold that in if
you would rather they move together.

One temporary commit to undo before merge

The PGO toolchain fetch is commented out, so this builds on emsdk's stock clang. Restore it once
MeshInspector/toolchains publishes clang-emsdk-5.0.7-pgo (building now; emsdk 5.0.7 ships
llvm-project 7b58716d9, clang 23.0.0git).

🤖 Generated with Claude Code