Rust whitelist preconfirmation driver does not retry bootnode/static peer dials

## Summary The Rust `whitelist-preconfirmation-driver` currently appears to dial configured bootnodes/static peers only once at startup. If the initial dial fails, or if the node starts before the relevant peer is reachable, the driver can remain subscribed to the preconfirmation gossipsub topics without any effective mesh peers and therefore receive no preconfirmation blocks. This was observed while investigating a mainnet `l2-node-reth` instance that was not inserting preconfirmation blocks. Its logs showed confirmed event-sync block insertion, but no inbound/imported preconfirmation payloads. A Masaya `l2-node-reth` instance, by contrast, was inserting preconfirmation blocks successfully. ## Relevant code In `packages/taiko-client-rs/crates/whitelist-preconfirmation-driver/src/network/runtime.rs`: - `WhitelistNetwork::spawn` classifies bootnodes and calls `dial_initial_peers` once. - `dial_initial_peers` calls `dial_once` for static peers and bootnode dial addrs. - `dial_once` records the address in `dialed_addrs`, then calls `swarm.dial(...)` once. - There is no retry/backoff/reconnect loop for failed or disconnected bootnode/static peer addresses. In `packages/taiko-client-rs/crates/whitelist-preconfirmation-driver/src/network/discovery.rs`: - `enode://...` bootnodes are converted into `/ip4/{ip}/tcp/{port}` direct dial addresses. - The enode pubkey and `discport` query are intentionally ignored. - discv5 discovery only starts for `enr:` bootnodes. If only `enode://` bootnodes are configured, the code logs that discovery is enabled but no ENR bootnodes were provided and skips discv5 bootstrap. ## Why this matters `libp2p gossipsub` maintains topic meshes among already connected peers, but it does not discover peers or retry bootnode dials by itself. Peer discovery/reconnection needs to be handled by the swarm/discovery/application layer. With the current behavior, a transient startup dial failure or an ineffective bootnode set can leave the node with no useful peers for the `preconfBlocks` topic. The process can look healthy, refresh the operator set, and continue confirmed event sync, while never receiving preconfirmation payloads. ## Suggested fix Add resilient peer connectivity for the whitelist preconfirmation network, for example: - periodically retry configured bootnode/static peer dials with backoff; - re-dial important static peers after disconnect; - expose/alert on connected peers and gossipsub mesh peers per topic; - support ENR-based discovery bootnodes in production configs, or document that `enode://` bootnodes only provide one-shot TCP dials; - consider accepting explicit libp2p multiaddr static peers for production preconfirmation deployments. ## Operational note Starting the optional REST/WS server via `--preconfirmation.rpc-addr` is not required for passive receipt of preconfirmation blocks. The P2P subscriber starts independently of the server; the server is only started when both `rpc_listen_addr` and `p2p_signer_key` are configured.