Subscribing to mempool events is flakey

[Mirko-von-Leipzig]

In #1495 we decoupled the ntx and block-producer start up processes. This is now possible because the ntx now streams accounts from the store instead of preloading them all.

This meant we could remove the Barrier which ensured the two components started in lock-step from the same chain tip. Now that we've removed this, the ntx's subscription to the mempool can fail if the block-producer has already created another block(s) after the ntx fetches the chain tip, but before it subscribes. Previously this was prevented because blocks were only built after the subscription was created due to the barrier.

We have two options here (afaict):

1. Loop fetch chain tip + subscribe until it succeeds.
   • Though this has poor semantics since it could fail for other reasons.
2. Remove chain tip from the endpoint.
   • This means the ntx doesn't actually know what the mempool's chain tip is until the first block committed event comes through.
   • So we could have start-up consist of buffering events until the first block comes in and only then starting the main event handler loop etc.

On first blush I'm partial to (2) because that feels less dependent on trial and error.

Here is an example error for reference:

2026-01-22T06:49:03.610906Z ERROR ntx.block_producer.client.subscribe_to_mempool: miden-ntx-builder: crates/ntx-builder/src/block_producer.rs:61: error: status: 'Client specified an invalid argument', self: "Mempool's chain tip 7 does not match request's 6", metadata: {"content-type": "application/grpc", "date": "Thu, 22 Jan 2026 06:49:03 GMT"}
2026-01-22T06:49:03.610934Z  INFO ntx.block_producer.client.subscribe_to_mempool: miden-ntx-builder: crates/ntx-builder/src/block_producer.rs:61: close, time.busy: 380µs, time.idle: 501ms
Error: Component ntx-builder failed

Caused by:
    0: failed while serving ntx builder component
    1: failed to subscribe to mempool events
    2: status: 'Client specified an invalid argument', self: "Mempool's chain tip 7 does not match request's 6", metadata: {"content-type": "application/grpc", "date": "Thu, 22 Jan 2026 06:49:03 GMT"}