RFC: Server should execute requests on a thread pool when client does not specify an execution thread

[ViniciusCestarii]

Referencing: https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/external-interfaces

Problem: IPC interface can be awkward to call due to threading

• Clients have to choose which thread asynchronous calls execute on, and create threads for calls to execute on
• Could be improved by server executing requests on a thread pool when client does not specify an execution thread

Currently, clients that call IPC methods must first call ThreadMap.makeThread to create a server-side worker thread and pass the resulting Thread handle in Context.thread on every call so it executes on a dedicated thread. Libmultiprocess abstracts this away for C++ clients, but clients that don't use libmultiprocess (which only supports C++) must handle this setup manually, making the IPC interface more awkward to call.

Proposed improvement: When a client passes a null/missing Context.thread, or when a method has no mp.Context parameter at all, the server should fall back to executing the request on a server-managed thread pool instead of blocking the event loop thread or failing with "invalid thread handle". This would simplify non-libmultiprocess clients that doesn't need a dedicated thread model.

Caveats:

• Callbacks require the client to still provide Context.callbackThread
• Response ordering is not guaranteed when requests from the same client land on different pool threads. The dedicated thread model avoids this by always queuing requests from the same client on one thread