fatp: Implement blockchain revert handling

[AlexandruCihodaru]

Add support for handling blockchain revert. This is useful in testing.

Changes:

• Add ChainEvent::Reverted variant to represent backward blockchain progression
• Implement handle_reverted() method that:
  • Collects transactions from retracted blocks via included_transactions cache or by fetching block bodies from the API
  • Removes all views beyond the revert point to prevent zombie views
  • Removes included transactions from mempool (they can be resubmitted later)
  • Updates enactment state (recent_finalized_block and recent_best_block)
  • Ensures a valid view exists at the revert target block
• Add early return in maintain() for Reverted events to prevent normal forward-progression logic from running

These changes fix issues where reverting would leave zombie views in the view store, causing issues at subsequent operations.

Note: Transactions that were pending may not be visible after revert if they fail the revalidation

[AlexandruCihodaru]

/cmd fmt

[AlexandruCihodaru]

/cmd prdoc --audience runtime_dev --bump patch

[michalkucharczyk]

DQ:

          D1-E1-F1-G1-..-X1
         /
A - B - C - D2-E2-F2-G2-..-X2
         \
          D3-E3-F3-G3-..-X3

Is it realistic scenario? Should we handle this properly? If we revert from X1 to B, shold we also remove all transactions included on D2-...-X2 and D3-...-X3 forks (as we do for D1-...-X1)?

If we assume that revert can only be called if there is single fork - should we somehow check this in handle_revert function? (or at least document it somehow).

[AlexandruCihodaru]

DQ:

          D1-E1-F1-G1-..-X1
         /
A - B - C - D2-E2-F2-G2-..-X2
         \
          D3-E3-F3-G3-..-X3

Is it realistic scenario? Should we handle this properly? If we revert from X1 to B, shold we also remove all transactions included on D2-...-X2 and D3-...-X3 forks (as we do for D1-...-X1)?

If we assume that revert can only be called if there is single fork - should we somehow check this in handle_revert function? (or at least document it somehow).

Excellent question. I think that in anvil it is not possible to have such a scenario but I believe that we should delete the transactions on all possible paths.

[AlexandruCihodaru]

/cmd fmt

[AlexandruCihodaru]

/cmd fmt

[paritytech-workflow-stopper[bot]]

All GitHub workflows were cancelled due to failure one of the required jobs. Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/19868343219 Failed job name: fmt

[AlexandruCihodaru]

/cmd fmt

[michalkucharczyk]

And one more "general" question - assuming that we have transaction that were submitted by submit_and_watch - will there be any event notifying that they were dropped once revert is done?