fix(runtime): re-check isolate liveness under the Locker in ObjC-to-JS callbacks - #475

An Objective-C callback implemented in JS (an exposed method on an extended class, or a JS block) can be invoked on any thread while the isolate that owns it is being torn down. Both entry points checked the isolate was alive before taking its Locker, but ~Runtime holds that lock while it removes the isolate's caches and clears the context. The pre-lock check could therefore pass, the lock be granted only after the caches were gone, and the callback continue with the dummy cache Caches::Get hands out for a disposed isolate, whose context persistent is empty: Caches::GetContext then dereferences null.

Seen on the shared spec Should not crash if the worker registers a notification, where the worker registers an NSNotificationCenter observer, the parent terminates it and posts the notification straight away: the main thread's post raced the worker thread's ~Runtime, and the crash report shows the observer's MethodCallback on the main thread with the worker in DisposeIsolateWhenPossible.

Both ArgConverter::MethodCallback and the JSBlock dispose helper now re-check IsolateWrapper::IsValid() once the Locker is held. ~Runtime erases the isolate from the live registry before it takes the lock, which is what makes the second look reliable; a caller that lost the race returns a zeroed result (or skips the persistent reset) instead of touching the dead isolate.

One window stays open and is out of scope here: a Locker taken on an isolate between the destructor's unlock and Isolate::Dispose. Closing it needs the registry mutex held across the check and the lock acquisition.

Suite: 1543 / 0 locally on top of main (19b880c).