When seek timesout, node's vm crash with EXC_BAD_ACCESS

The following code will make it crash if it times out to seek to something in the past

```typescript
const consumeSince = new Date(new Date() - 7 * 24 * 24 * 60 * 1000);

const consumer = await client.subscribe({
topic: fullTopicName,
subscription,
subscriptionType: 'Exclusive' as SubscriptionType,
subscriptionInitialPosition: 'Latest' as InitialPosition,
consumerName,
listener: async (message: Message, listenerConsumer: Consumer) => {}
});

await consumer.seekTimestamp(consumeSince.valueOf());
```

Will crash with the following:
```
Process 32926 stopped
* thread #24, stop reason = EXC_BAD_ACCESS (code=1, address=0x276)
frame #0: 0x000000011e096b04 pulsar.node`Consumer::SeekTimestamp(Napi::CallbackInfo const&)::$_10::__invoke(pulsar_result, void*) + 64
pulsar.node`Consumer::SeekTimestamp(Napi::CallbackInfo const&)::$_10::__invoke(pulsar_result, void*):
-> 0x11e096b04 <+64>: ldadd x9, x8, [x8]
0x11e096b08 <+68>: ldr x23, [x22, #0x8]
0x11e096b0c <+72>: cbz x23, 0x11e096b20 ; <+92>
0x11e096b10 <+76>: add x8, x23, #0x8
Target 0: (node) stopped.
(lldb) bt
* thread #24, stop reason = EXC_BAD_ACCESS (code=1, address=0x276)
* frame #0: 0x000000011e096b04 pulsar.node`Consumer::SeekTimestamp(Napi::CallbackInfo const&)::$_10::__invoke(pulsar_result, void*) + 64
frame #1: 0x000000011e20d6f8 pulsar.node`void pulsar::MultiTopicsConsumerImpl::seekAllAsync(unsigned long long const&, std::__1::function)::'lambda'(std::__1::shared_ptr const&, pulsar::SharedFuture)::operator()(std::__1::shared_ptr const&, pulsar::SharedFuture) const::'lambda'(pulsar::Result)::operator()(pulsar::Result) const + 164
frame #2: 0x000000011e1c3390 pulsar.node`std::__1::__function::__func const&, std::__1::function)::$_18, std::__1::allocator const&, std::__1::function)::$_18>, void (pulsar::Result, pulsar::ResponseData const&)>::operator()(pulsar::Result&&, pulsar::ResponseData const&) + 508
frame #3: 0x000000011e148fa4 pulsar.node`pulsar::InternalState::complete(pulsar::Result, pulsar::ResponseData const&) + 192
frame #4: 0x000000011e1050bc pulsar.node`pulsar::ClientConnection::handleRequestTimeout(std::__1::error_code const&, pulsar::ClientConnection::PendingRequestData) + 84
frame #5: 0x000000011e149718 pulsar.node`asio::detail::binder1::operator()() + 144
frame #6: 0x000000011e149164 pulsar.node`asio::detail::wait_handler::do_complete(void*, asio::detail::scheduler_operation*, std::__1::error_code const&, unsigned long) + 280
frame #7: 0x000000011e122ebc pulsar.node`asio::detail::scheduler::do_run_one(asio::detail::conditionally_enabled_mutex::scoped_lock&, asio::detail::scheduler_thread_info&, std::__1::error_code const&) + 668
frame #8: 0x000000011e122ad0 pulsar.node`asio::detail::scheduler::run(std::__1::error_code&) + 268
frame #9: 0x000000011e1d124c pulsar.node`void* std::__1::__thread_proxy[abi:ue170006]>, pulsar::ExecutorService::start()::$_0>>(void*) + 176
frame #10: 0x000000018f162c0c libsystem_pthread.dylib`_pthread_start + 136
```

Reproduziere das Timeout mit Consumer::SeekTimestamp und verfolge anschließend den Callback über seekAllAsync, seekAsyncInternal und ClientConnection::handleRequestTimeout im Stack. Ermittle, wo das Timeout-Ergebnis den nativen Callback erreicht, und überprüfe, dass dasselbe Szenario ohne einen EXC_BAD_ACCESS-Absturz abgeschlossen wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.