feat(engine-byzantine): add crate for simulating Byzantine faults in consensus

[hvanz]

Closes: #1504

This PR introduces a new engine-byzantine crate that provides configurable Byzantine behavior simulation, along with a comprehensive integration test suite that exercises vote equivocation, proposal equivocation, message dropping, amnesia attacks, and consensus stall scenarios.

The new crate provides two main components that compose with the existing engine architecture:

• ByzantineNetworkProxy: A ractor actor that sits between the consensus actor and the real network actor. It intercepts outgoing PublishConsensusMsg and PublishLivenessMsg messages and can drop them (simulating silence/censorship), duplicate them with conflicting content (simulating equivocation), or forward them unchanged. All other message types pass through transparently.

• ByzantineMiddleware: Wraps the test app's Middleware trait to override vote construction. When ignore_locks is enabled, it tracks proposed values and overrides nil prevotes to vote for the most recently proposed value, simulating an amnesia attack (ignoring the Tendermint voting lock mechanism).

Both components are driven by a ByzantineConfig struct that supports five attack types:

Attack	Config field	Description
Vote equivocation	equivocate_votes	Sends original vote + a conflicting vote (value flipped to nil)
Proposal equivocation	equivocate_proposals	Sends original proposal + a proposal with a different value
Vote dropping	drop_votes	Silently drops outgoing votes (on both consensus and liveness channels)
Proposal dropping	drop_proposals	Silently drops outgoing proposals
Amnesia	ignore_locks	Votes for the current round's proposed value even when locked on a different value

Each attack is gated by a Trigger that controls when it fires: Always, Random { probability }, AtHeights, AtRounds, or HeightRange.

Also, integrated the Byzantine engine with test app (crates/test/app/):

• Added ByzantineConfig as an optional field on the test app's Config struct.
• Modified App::start() to conditionally spawn a ByzantineNetworkProxy in front of the real network actor and wrap the middleware with ByzantineMiddleware when amnesia is configured.

Testing

The following integration tests where added to crates/test/tests/it/byzantine_engine.rs:

1-of-4 Byzantine node scenarios (minority fault):

• vote_equivocation_detected — Verifies honest nodes collect MisbehaviorEvidence for vote equivocation.
• proposal_equivocation_detected — (Currently #[ignore]) Verifies proposal equivocation detection. Known limitation: gossip latency causes conflicting proposals to arrive after height decision.
• proposal_dropping_liveness — Confirms the network progresses when one node drops all proposals.
• vote_dropping_liveness — Confirms the network progresses when one node drops all votes.
• amnesia_attack_liveness — Confirms the network progresses despite one node ignoring voting locks.

2-of-4 Byzantine node scenarios (exceeding fault threshold):

• two_byzantine_of_four_stalls_consensus — Verifies that when 2 of 4 equal-power nodes drop all votes (50% of voting power), consensus correctly stalls (no decisions made), confirming the f < n/3 fault threshold.
• two_silent_of_four_stalls_consensus — Same as above but with both votes and proposals dropped.
• two_proposal_droppers_of_four_still_progresses — Verifies that dropping proposals alone (while still voting) does not prevent liveness, since honest proposer rounds still succeed.
• two_vote_equivocators_of_four_detected — Verifies equivocation evidence is collected even with 2 equivocating nodes.
• two_amnesia_of_four_still_progresses — Verifies that amnesia alone does not break liveness when all votes are still delivered.

---

PR author checklist

Contribution eligibility

• I am a core contributor, OR I have been explicitly assigned to the linked issue
• I have read CONTRIBUTING.md and my PR complies with all requirements
• I understand that PRs not meeting these requirements will be closed without review

For all contributors

• Reference a GitHub issue
• Ensure the PR title follows the conventional commits spec
• Add a release note in RELEASE_NOTES.md if the change warrants it
• Add an entry in BREAKING_CHANGES.md if the change warrants it

For external contributors

• Maintainers of Malachite are allowed to push changes to the branch