txconfirm: BumpCount increments on a failed fee-bump

[Roasbeef]

Summary

The tracked-tx BumpCount is incremented even when a fee-bump attempt fails, so it counts "fee-bump attempts that returned to AwaitingConfirmation" rather than successful bumps.

Detail

Two facts combine:

• In txconfirm/states.go, trackedTxStateFeeBumping.ProcessEvent handles trackedTxBroadcastAccepted by doing progress.BumpCount = s.BumpCount + 1 and transitioning FeeBumping -> AwaitingConfirmation.
• In txconfirm/actor.go handleBlockObserved, the fee-bump failure recovery advances the FSM with the same trackedTxBroadcastAccepted event to recover FeeBumping -> AwaitingConfirmation.

Because the failure path reuses the success event, a fee bump whose broadcaster.Submit returned an error increments BumpCount identically to one that actually landed.

Impact

Informational. BumpCount lives in trackedTxProgress for diagnostics/observability; nothing branches on it for correctness (no fee math or retry cap reads it). The only consequence is a misleading counter.

Fix

Give the failure path its own event (e.g. trackedTxFeeBumpFailed) that recovers FeeBumping -> AwaitingConfirmation without incrementing BumpCount, or only increment on a confirmed-successful submit.

Discovery

Found during the multi-agent review of the #509 checkpoint-broadcast-hardening change (darepo-client#663). Pre-existing; not introduced by that PR.

[fzlzjerry]

I would like to work on this. I will add an explicit fee-bump-failed FSM event so failed interval and BumpNow attempts return to AwaitingConfirmation without incrementing BumpCount, preserve the previous successful broadcast metadata while updating the retry height, and add FSM and actor regression tests before running the txconfirm test and lint gates.