…p robustness (#2013)

* fix: runtime lifetime — deferred leaks, cross-isolate sharing, startup robustness

Works through the tracking issue left by #2006/#2008, minus the HMRSupport
item (handled separately).

Startup:
- Main-runtime election and the once-per-process V8 initialization now happen
  in one critical section, so two concurrent bootstraps cannot both elect
  themselves and overwrite Runtime::platform / s_mainEventLoop. A runtime that
  loses the election waits for the main runtime to publish the metadata tree it
  reads, instead of relying on call ordering.
- A native initialization that throws after Isolate::New is unwound through the
  existing two teardown windows rather than left half-built; the Runtime itself
  is freed instead of leaking with its isolate still in the caches.

Leaks:
- MetadataNodeCache now owns every callback payload handed to V8 as External or
  FunctionTemplate data (MethodCallbackData, FieldCallbackData,
  PropertyCallbackData, TypeMetadata, ExtendedClassCallbackData). V8 finalizes
  none of them, so they leaked on every GC. An arena, because the same
  MethodCallbackData is shared between a prototype method, CtorCacheData and
  derived classes.
- ModuleInternal::m_loadedModules is released at teardown, deduplicated by
  pointer (a module is cached under two keys), and a failed load no longer
  leaks its module handle.
- The JS error handed to Java as jsValueAddress is now an id into a per-runtime
  table instead of a raw Persistent* Java could never free. The entry is
  dropped when the error is converted back, when the throwable is collected, or
  with the runtime — this was the only leak that grew inside a live runtime.

Cross-isolate sharing:
- MetadataNode's three process-wide node caches are guarded. The lock covers
  map access only and is dropped around the metadata reader.
- MetadataReader's node vector, value-buffer bump allocator, type-name cache
  and memoized node types are guarded by a reentrant lock that can be released
  to zero mid-section, so it is never held across the Java call that resolves
  an unknown type (ART class loading, and dex generation on the .extend()
  path). GetNodeById is bounds-checked.

Also makes IsolateDisposer.h's two namespace-scope definitions inline (ODR).

* refactor: move isolate-bound objects into RuntimeState

`isolateBoundObjects_` was a process-wide Isolate*-keyed map behind a mutex --
the same shape RuntimeState exists to remove -- and it held exactly one object
per runtime: Timers.

Timers now lives in RuntimeState like every other per-runtime subsystem, so the
map, its mutex and the unique_void_ptr machinery are deleted rather than made
inline, which resolves the ODR item by removing the definitions. disposeIsolate
stays for the two builtin-layer hooks.

Timers is consequently destroyed at m_state->Clear() instead of inside
disposeIsolate. ~Timers -> Destroy() touches only its own task map, the event
loop and the tasks' Java token peers -- nothing torn down in between -- and both
the isolate and JNI are still alive at Clear(), which is what resetting the task
handles and deleting the token global refs require.

* refactor: move the builtin layer's isolate state into RuntimeState

BuiltinLoader kept two Isolate*-keyed process-wide maps (isolateToPrimordials,
isolateToBuiltinRequire) and NsBuiltinModules a third (isolateToRealm), each
behind its own mutex -- the same shape RuntimeState exists to remove. The
primordials lookup runs on every builtin call, so that one took a lock on a hot
path to reach state that was never actually shared.

All three become per-runtime state: a BuiltinRealm holding the two handles as
v8::Globals, and RealmState, which was already a per-runtime struct with a
destructor. Reaching either is now an isolate data-slot read plus a vector
index, and both are released with the runtime while its isolate is alive.

GetRealm can now return null (the runtime has begun tearing down), so its four
callers degrade rather than resurrect state teardown already released;
Instantiate keeps its contract of leaving an exception pending.

With nothing left to release per isolate, disposeIsolate and IsolateDisposer
are deleted along with the DestroyRuntime call site. RealmState and the
BuiltinLoader handles are consequently destroyed at m_state->Clear() instead;
neither destructor runs JS or touches anything torn down in between, and
~RealmState only deletes v8::Persistents, which never call into V8.

* fix: unique JS error handle ids, and diagnose bad metadata node ids

Two review findings on this branch.

The JS error handle id was minted from a per-runtime counter, so every runtime
produced 1, 2, 3... A throwable converted back to JS on a runtime other than the
one that created it would then find an unrelated entry under the same id and
consume it, instead of missing and falling back to rebuilding the error from the
Java throwable. Ids are now unique process-wide, which is what makes the table
lookup itself the ownership check.

GetNodeById's new bounds check turned an out-of-range read into a nullptr its
callers still dereferenced. It now logs the offending id, ReadTypeName and the
array-element lookup in GetNodeType throw a NativeScriptException naming the
problem, and GetBaseClassNode returns null -- which every caller already treats
as "no base class". The assert it relied on was a no-op in release, where the
bounds check was missing entirely.

Also asserts the ownership precondition in StateMutex::Unlock and ReleaseAll: an
unmatched unlock would wrap depth_ and hold the mutex forever, and a non-owner
ReleaseAll would drop another thread's lock mid-section.