iOS Crashing: Max heap size was exceeded

## Bug Description

Since switching to Hermes, one of our customers is reporting continual crashing 45-60 seconds after opening the app.

Sentry is reporting the following:

**EXC_BAD_ACCESS** RNSScreen
```
EXC_BAD_ACCESS
, message = > [] reason = Max heap size was exceeded (1 from category: vm_allocate_category), numCollections = 1546, heapSize = 910163968, allocated = 888660456, va = 910163968, external = 2560326059 > lue = > natural > OOM: error_code(value = 1, category = vm_allocate_category, message = Max heap size was exceeded) > y = vm_allocate_category, message = Max heap size was exceeded) > ZTUM >
Attempted to dereference null pointer.
```

Trace looks like:
```
hermes +0x03aba8 facebook::jsi::JSError::~JSError
hermes +0x03a368 facebook::jsi::JSError::~JSError
hermes +0x021718 facebook::jsi::JSError::~JSError
hermes +0x02104c facebook::jsi::JSError::~JSError
hermes +0x00b948 facebook::hermes::HermesRuntime::rootsListLength
inspectflowplus +0x22a6c0 facebook::jsi::RuntimeDecorator::call (decorator.h:297) In App
inspectflowplus +0x22a6c0 facebook::jsi::WithRuntimeDecorator::call (decorator.h:700) In App
inspectflowplus +0x25bd7c facebook::jsi::Function::call (jsi-inl.h:228) In App
inspectflowplus +0x25bd7c facebook::jsi::Function::call (jsi-inl.h:233) In App
inspectflowplus +0x25bd7c facebook::jsi::Function::call (jsi-inl.h:241) In App
inspectflowplus +0x25bbe0 facebook::react::JSIExecutor::callFunction::lambda::operator() (JSIExecutor.cpp:256)
inspectflowplus +0x25bbe0 std::__1::__invoke (type_traits:3918)
inspectflowplus +0x25bbe0 std::__1::__invoke_void_return_wrapper::__call (invoke.h:61)
inspectflowplus +0x25bbe0 std::__1::__function::__alloc_func::operator() (function.h:178)
inspectflowplus +0x25bbe0 std::__1::__function::__func::operator() (function.h:352)
inspectflowplus +0x15e83c std::__1::__invoke (type_traits:3918)
inspectflowplus +0x15e83c std::__1::__invoke_void_return_wrapper::__call (invoke.h:61)
inspectflowplus +0x259150 std::__1::__function::__value_func::operator() (function.h:505)
inspectflowplus +0x259150 std::__1::function::operator() (function.h:1182)
inspectflowplus +0x259150 facebook::react::JSIExecutor::callFunction (JSIExecutor.cpp:254)
inspectflowplus +0x203128 std::__1::__function::__value_func::operator() (function.h:505)
inspectflowplus +0x203128 std::__1::function::operator() (function.h:1182)
inspectflowplus +0x203128 facebook::react::NativeToJsBridge::runOnExecutorQueue::lambda::operator() (NativeToJsBridge.cpp:310)
inspectflowplus +0x203128 std::__1::__invoke (type_traits:3918)
inspectflowplus +0x203128 std::__1::__invoke_void_return_wrapper::__call (invoke.h:61)
inspectflowplus +0x203128 std::__1::__function::__alloc_func::operator() (function.h:178)
inspectflowplus +0x203128 std::__1::__function::__func::operator() (function.h:352)
inspectflowplus +0x161748 std::__1::__function::__value_func::operator() (function.h:505)
inspectflowplus +0x161748 std::__1::function::operator() (function.h:1182)
inspectflowplus +0x161748 facebook::react::tryAndReturnError (RCTCxxUtils.mm:74)
inspectflowplus +0x16c88c facebook::react::RCTMessageThread::tryFunc (RCTMessageThread.mm:69)
inspectflowplus +0x16c640 std::__1::__function::__value_func::operator() (function.h:505)
inspectflowplus +0x16c640 std::__1::function::operator() (function.h:1182)
inspectflowplus +0x16c640 facebook::react::RCTMessageThread::runAsync (RCTMessageThread.mm:45)
```

There are 19 similar Sentry reports from the last few days from that user, each with a different heapSize.
Could definitely use some help.

- [ ] I have run `gradle clean` and confirmed this bug does not occur with JSC

Hermes version: 0.11.0
React Native version (if any): 0.68.1
OS version (if any): iOS 17 (though it was happening with 16.6.1 as well)
Device: iPad 13.10

## Steps To Reproduce

1. Haven't been able to reproduce locally

## The Expected Behavior

Should not throw Max Heap size error when heap size is much less than 3 GB.

Start with the reported Hermes 0.11.0 and React Native 0.68.1 configuration on iOS, then trace the crash through HermesRuntime::rootsListLength and JSIExecutor.cpp. The issue has no local reproduction, so first seek a reproducible case matching the Sentry heap-growth reports. Done means identifying the cause and demonstrating that the max-heap crash no longer occurs with a regression test or verified reproduction.

Written by the indexing model from the issue text.