Do not let an invalid peer block take the node offline

[1440000bytes]

A single block from a peer that fails consensus validation permanently kills the net task, taking the node's networking fully offline.

In the NewTipReady handler, reorg_to_tip(...)? propagates any error out of run():

let reorg_applied = task::block_in_place(|| {
    reorg_to_tip(&self.ctxt.env, &self.ctxt.archive,
                 &self.ctxt.mempool, &self.ctxt.state,
                 #[cfg(feature = "zmq")] &self.ctxt.zmq_pub_handler,
                 new_tip)
})?;

run()'s caller only logs the error and lets the task end:

if let Err(err) = task.run().await {
    tracing::error!("Net task error: {err:#}");
}

So when a peer sends a block whose body fails state validation e.g. a transaction with value out > value in, surfacing as state error: value in is less than value out (NotEnoughValueIn) the whole net task dies. After that nothing services peer connections, producing an endless stream of Failed to send peer connection info and Failed to send response info. The offending peer isn't even dropped (addr is discarded).

This means any peer can permanently disable a node's networking with one invalid block (remote DoS), and any genuine consensus disagreement bricks the node instead of just rejecting that chain.

Fix

Classify reorg errors. A State error is caused by a peer's invalid block and must not be fatal: log a warning, drop the offending peer, and keep running. All other errors (db / env / net infrastructure) still propagate.

reorg_to_tip only commits its write txn on success, so on the error path the pre-reorg tip is left intact and continuing is safe.

---

Related PR: LayerTwo-Labs/thunder-rust#102

Note: Both issues were reported by BTCapsule in drivechain telegram group: https://t.me/c/1378593808/234819