GeezerVison

Supersedes #512, which found the race this fixes. Thanks @adrian-niculescu.

Problem

Setting up a runtime was assembled by hand at each call site:

• Main (NativeScript.mm): new Runtime(), CreateIsolate(), Locker, Init(isolate).
• Worker (Worker.mm): the same, plus WatchHeapLimit before Init(isolate, true) and SetWorkerId after it.

That split caused several problems:

• Startup race. CreateIsolate added the isolate to the live registry (isolates_) before Init wrote its Caches slot. Runtime::NotifyMemoryPressure (feat(runtime): report native memory held by wrappers to V8, forward memory pressure #507) runs on a dispatch queue and reads that slot for every registered isolate, so a memory-pressure event during startup could read it while it was being written. On a miss it also built a stand-in Caches off-thread. fix(runtime): publish an isolate's Caches under the registry lock #512 fixed this by writing the slot under the registry lock; this PR removes the window instead.
• Wrong worker flag. SetWorkerId ran after Init, so Runtime::IsWorker() returned false during a worker's Init. That includes worker-scoped class naming in ClassBuilder and the main-isolate-only checks in ns:runtime.
• Leaked isolates. CreateIsolate could be called more than once on the same Runtime. And a Runtime deleted before Init left its isolate registered and never disposed, because isolate_ was only set at the end of Init.

Change

• Runtime(const RuntimeOptions&) creates the isolate on the calling thread, which becomes its home thread. The isolate limits and the worker id are passed in up front, so IsWorker() is correct from the start.
• The caller still takes the Locker and can work with the isolate before it's ready; the worker arms WatchHeapLimit there. It then calls Init().
• Init() adds the isolate to the registry only after writing its Caches slot. Teardown already removes it from the registry before clearing the slots. So any thread that finds an isolate in the registry may read its slots while holding the registry lock. This rule is documented on isolates_, and the memory-pressure handler relies on it unchanged.
• A Runtime deleted before Init disposes its isolate, which no other thread has seen yet.
• CreateIsolate and SetWorkerId are removed. Runtime.h is a project header, not part of the public framework headers.

Not covered

A reader that finds the isolate in the registry, releases the lock, and only then reads the slot can still race teardown's Caches::Remove. The pre-Locker IsolateWrapper::IsValid() in ArgConverter::MethodCallback does this. That's a separate fix: read the slot only under the isolate's Locker.

Tests

No new test: the startup overlap depends on timing (see #512 for a sleep-based repro). The full suite under ASan on a dedicated simulator gives 1835 specs, 0 failures, and no sanitizer reports.

Summary by CodeRabbit

• Refactor
  • Runtime setup now applies resource limits and worker identification from the outset. Initialization and cleanup follow a consistent lifecycle for both standard and worker runtimes.