fix(p2p): apply chain recovery policy to corrupted storage

[web3blind]

Summary

Follow-up to #179, scoped to the two P2P corruption-routing gaps found during review.

• Route incoming P2P transactions through the chain transaction entrypoint, so typed storage corruption invokes the existing recovery/shutdown policy. Handle the already-processed local fault at the P2P delegate boundary without disconnecting the sending peer.
• Handle corruption explicitly during the block retry after a fork-db reset; do not fall through to ALREADY_KNOWN.
• Share the existing chain corruption policy with initial/retried P2P block processing, including application shutdown when automatic recovery is disabled.
• Add offline regression scenarios to CI and document their scope.

This PR does not contain the changes from #179, change consensus/wire formats, update chainbase, or fix the separate undo-session destructor issue identified in that audit. It can be reviewed independently against master.

Verification

• python3 tests/p2p/test_corruption_recovery.py -v — passes 26 compiled C++ scenarios using the actual production entrypoint/policy and network transaction-handler bodies with controlled storage/application dependencies.
• Both complete changed production translation units passed C++14 -fsyntax-only with the repository submodule headers, Boost 1.83 and the generated hardfork header.
• git diff --check — clean.

The regressions cover enabled/disabled recovery, transaction corruption and ordinary transaction outcomes, initial and retried block corruption, ordinary block classification, unchanged synchronization skip flags, and recovery exceptions escaping nested retry handling. They do not run a live node or perform snapshot restoration.

Full node linking, the full consensus suite, and end-to-end snapshot recovery were not run locally. No production deployment was performed.