Intermittent SIGSEGV in Maglev concurrent compilation on Linux (PersistentHandles::GetHandle) — regression between v24.14.1 and v24.15.0

### Version v24.15.0 through v24.18.1 (current LTS). v24.14.1 is not affected. ### Platform Linux 6.8.0-136-generic x86_64 (Ubuntu 24.04.4, glibc 2.39) — also observed on GitHub Actions `ubuntu-latest`. Not the Windows-only issue from #62991 (that was fixed in v24.16.0; this reproduces on Linux through v24.18.1). ### Subsystem v8 (Maglev) ### What steps will reproduce the bug? The trigger is CPU-hot JS tiering up to Maglev while the machine is CPU-starved, so the repro pins several node processes to two cores. I hit it with an undici test that runs tight request/teardown loops, but the crash is in V8's concurrent compiler thread and has nothing to do with undici's native surface (no addons; the crashing thread is a Maglev compile job): ```bash git clone https://github.com/nodejs/undici.git && cd undici # tested at c76fe46e npm i for i in $(seq 1 6); do (taskset -c 0,1 node test/http2-request-never-settles.js >/dev/null 2>&1; echo "run $i: exit $?") & done; wait ``` Repeat the batch a few times; on v24.18.x roughly 1 in 5–10 processes exits 139 (SIGSEGV) with no output. ### How often does it reproduce? Is there a required condition? With 6 processes pinned to 2 cores (48 runs per version, same machine): | Node | V8 | SIGSEGV rate | |---|---|---| | v24.14.1 | 13.6.233.17-node.44 | 0/96 | | v24.16.0 | 13.6.233.17-node.49 | 1/48 | | v24.18.0 | 13.6.233.17-node.50 | 9/48 | | v24.18.1 | 13.6.233.17-node.50 | 5/48 | | v24.18.1 `--no-maglev` | 13.6.233.17-node.50 | 0/48 | CPU contention is the required condition — on an idle machine with a single process it passes reliably. `--no-maglev` eliminates the crash entirely. The regression window is the V8 cherry-picks between `13.6.233.17-node.44` (v24.14.1) and `-node.48/49` (v24.15.0/v24.16.0), with the rate increasing at `-node.50`. ### What is the expected behavior? Why is that the expected behavior? The process should not segfault. ### What do you see instead? The child dies on SIGSEGV with no output at all, which surfac…