A bundle_id is a receipt, NOT a landing guarantee. We poll in-flight
status a bounded number of times (maxBundlePolls) and, on anything
other than a confirmed "Landed", hand the SAME already-signed wire
transaction to the RPC TransactionSender. The fallback inherits the
sender's invariants (maxRetries:0, no re-sign, LVBH-bounded loop), so
there is no double-charge and the path is idempotent by signature.
On the Jito-landed path we do NOT poll the cluster for confirmation:
a "Landed" bundle IS the confirmation. The transaction may never have
been broadcast to the RPC, so a getSignatureStatuses poll would falsely
expire it. We return outcome "confirmed" with slot null directly.
Submit via Jito; fall back to RPC sender if the bundle doesn't land.
Correctness invariants (see CLAUDE.md):
bundle_idis a receipt, NOT a landing guarantee. We poll in-flight status a bounded number of times (maxBundlePolls) and, on anything other than a confirmed "Landed", hand the SAME already-signed wire transaction to the RPCTransactionSender. The fallback inherits the sender's invariants (maxRetries:0, no re-sign, LVBH-bounded loop), so there is no double-charge and the path is idempotent by signature.