fix(qt_remote): defer async completion delivery off the QtRO read stack (#7)

A `concurrency:"multi"` call's result comes back as a deferred completion
event (`__logos_call_complete__`), delivered by RemoteEventHelper::onEventResponse
— a slot fired by the replica's eventResponse signal. Cross-process, that slot
runs on QtRO's read stack (QRemoteObjectNodePrivate::onClientRead). Until now the
async user callback was invoked *inline* there, and that callback routinely (a)
emits a module event — which the host-side ModuleProxy serializes onto the QtRO
source — and (b) release()s the client object. Doing either while onClientRead is
still unwinding re-enters QtRO and corrupts the node: a SIGSEGV in onClientRead
(EXC_BAD_ACCESS, KERN_INVALID_ADDRESS at 0x80). This is the crash the EVM wallet
backend hit from refresh_balances, which fans balance reads out to eth_rpc via
call_async and then emits `balances_updated` from the gather completion.

Primary fix (remote_transport.cpp): deliver the async completion callback on the
next event-loop turn via QTimer::singleShot(0, m_helper, …) instead of inline, so
all user code (event emits, release(), further calls) runs after onClientRead has
fully unwound. m_helper is the context so the callback is dropped if the object is
torn down first.

Defense-in-depth for the same re-entrancy class:
- remote_transport.cpp release()/disconnectEvents()/dtor: deleteLater() the helper
  (signal receiver) and replica (signal sender) and disconnect first, instead of
  deleting them inline — deleting a QObject mid-emission corrupts the connection
  list Qt is iterating.
- module_proxy.cpp: always queue the source eventResponse emit to the owning
  thread (Qt::QueuedConnection), never emit inline, so a module that emits from
  inside a same-thread dispatch can't re-enter QtRO's source serialization.

Tests (tests/protocol/test_remote_transport_events.cpp, newly wired): qt_remote
LocalSocket event delivery (direct + full provider chain) and a reentrant-release
regression that drives release() from inside a deferred-completion callback. The
hard crash only reproduces cross-process (in-process QtRO posts the event, so the
read stack has already unwound) — the cross-process guard is the wallet Anvil
integration doctest, where this fix is A/B-proven: the published backend crashes
on refresh_balances, the patched backend returns balances cleanly.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

cpp/module_proxy.cpp

@@ -19,15 +19,23 @@ ModuleProxy::ModuleProxy(LogosProviderObject* provider, QObject* parent)
             // driven from its own thread. Emitting directly from a foreign
             // thread runs QtRO's source serialization there, racing the source
             // socket against a reply being sent from the source thread, which
-            // can silently drop the reply. AutoConnection keeps same-thread
-            // callers synchronous (the common case) and only queues the
-            // emission when it arrives from another thread, so events and
-            // replies stay serialized on the thread QtRO expects to own the
-            // source. Passing `this` as the context also cancels a queued
-            // emission if this object is destroyed first.
+            // can silently drop the reply.
+            //
+            // We *always* queue the emission to this object's own thread, never
+            // emit inline — even for a same-thread caller. A module that emits an
+            // event from inside an async-call-completion callback (e.g. a
+            // gather/fan-out completion firing `balances_updated` from within the
+            // `__logos_call_complete__` reply dispatch) is on the source thread,
+            // so an AutoConnection would run QtRO's source serialization for the
+            // event *re-entrantly*, while a reply is still being marshalled on the
+            // same stack — corrupting the source and crashing (SIGSEGV). A queued
+            // connection defers the emit to the next event-loop turn, after the
+            // reply has been sent, so events and replies stay serialized on the
+            // thread QtRO owns. Passing `this` as the context also cancels a
+            // queued emission if this object is destroyed first.
             QMetaObject::invokeMethod(this, [this, eventName, data]() {
                 emit eventResponse(eventName, data);
-            }, Qt::AutoConnection);
+            }, Qt::QueuedConnection);
         });
         qDebug() << "[LogosProviderObject] ModuleProxy: created, wrapping LogosProviderObject"
                  << m_provider->providerName();