Reduce RBF publication latency while preserving success ordering #1822

Android PR #1813 intentionally waits for the exact replacement activity and metadata before showing Boost success. At d368822, device review measured native bumpFeeByRbf return → Boosted toast at 4.13 s versus 0.35 s on master 74c8b2c (medians of 3). Swipe → toast was 5.90 s versus 1.84 s.

Setup: E2E=true E2E_BACKEND=local, Gate_Throwaway, fresh wallet, local bitcoind funding/mining. Device review and source discussion: #1813 (comment) and #1813 (review)

The delay includes wallet sync and replacement/received-event handling. Waiting for publication is a required correctness guarantee, so early success is not an acceptable optimization. This is a LOW performance/UX follow-up, not a failing J1 result; all 13 J1 steps passed at that revision.

Profile the sync/event/metadata boundary and evaluate reducing latency or a bounded transition into Boost Pending, while retaining exact replacement identity, complete metadata before success, stale-row routing, the approved fee quote, cancellation and single-attempt ownership. Do not add sleeps, weaken financial assertions, or report success merely because native code returned a TXID.

Acceptance: recorded before/after timings at exact revisions with repeated samples; J1 and the controlled pending/retry case still pass; failure/cancellation tests remain detecting; success never precedes durable replacement publication.