fix(sync): pull Malachite suffix-gap fix

[huklaa]

Fixes #214.
This updates the Malachite revision to include the upstream suffix-gap fix that addresses the remaining follower-sync deadlock path.
PR #227 only moved Arc to an earlier Malachite revision and explicitly did not include this suffix-gap fix, so this is a separate follow-up scope.
The updated Malachite revision preserves the requested suffix when a missing prefix is re-requested, preventing the follower from losing the suffix and getting stuck in a sync loop.
Validation:
cargo build -p arc-node-consensus --locked
targeted regression coverage is included upstream in Malachite commit 378b0e5

[osr21]

Verified the scope of this bump against upstream before anything else, since consensus-dep pins deserve suspicion. The core claims all check out:

• 8ee5d998 → 378b0e5 is a clean fast-forward on circlefin/malachite main — exactly 3 commits ahead, 0 behind, and 378b0e5 is reachable from main (one behind the current tip), so the pin is safe from ref GC. The only Rust change across the whole delta is code/crates/sync/src/handle.rs; everything else is Malachite's own CI workflows, which are irrelevant to the vendored crates.
• The fix targets the right branch of Follower sync deadlock: failed multi-height fetch skips a height, consensus wedges permanently (v0.7.3) #214. chore(deps): bump malachite pin to current main — hardens no-peer sync branch #227's own scope note conceded that #1567 only hardens the no-peer-available rollback, while the reported wedge came from the branch where a peer is available but only covers a prefix of the failed range. 378b0e5 is precisely that branch — the trimmed suffix is re-requested from another peer instead of being dropped below sync_height — and the upstream patch adds test_re_request_covers_trimmed_suffix_to_other_peer, so the "regression coverage included upstream" claim is real, not aspirational.
• This strictly supersedes chore(deps): bump malachite pin to current main — hardens no-peer sync branch #227 (still open): the new pin transitively includes 5cd137fb/#1567, so both sync fixes land in one bump. If this merges, chore(deps): bump malachite pin to current main — hardens no-peer sync branch #227 should be closed as superseded.

One thing I'd fix before merge:

The Cargo.lock diff contains churn the pin change doesn't require. Malachite's own manifests are untouched between the two revs (the upstream compare shows no Cargo.toml/Cargo.lock changes), so the only necessary lock edits are the arc-malachitebft-* source lines. But this lock also moves unrelated registry crates: windows-sys hops (0.48.0/0.59.0 → 0.60.2/0.61.2), itertools downgrades from 0.12.1 to 0.10.5 inside four prost-build variants, and a syn 2.0.117 → 1.0.109 flip. That pattern says the lock was regenerated more broadly than cargo needed for a git-pin bump. For a consensus repo the lock delta on a dep bump should be exactly auditable — and downgrades in particular can silently reintroduce fixed behavior in build-time deps. Suggest resetting Cargo.lock to main's copy, editing only the rev fields, and letting a plain cargo build refresh just the git pins; the diff should then collapse to the ~19 malachitebft entries.

Two smaller notes:

• Validation is compile-only. cargo build --locked proves resolution, not behavior — worth running the sync-adjacent test suites here, and ideally a quake follower scenario shaped like the Follower sync deadlock: failed multi-height fetch skips a height, consensus wedges permanently (v0.7.3) #214 wedge (multi-height fetch failure with a prefix-only peer), since that's the exact path this changes and the upstream test exercises Malachite's handler in isolation, not Arc's integration of it.
• Cosmetic: the new pins use a 7-char rev (378b0e5) where the repo convention is 8 (8ee5d998, 5cd137fb). Harmless to cargo, mildly annoying to grep.

Also a practical heads-up given #282 is in flight: #214 currently has no assignee, and under the incoming PR gate this PR's author would need to be assigned to it. A maintainer assigning @huklaa to #214 would both reflect reality and keep this PR from tripping the new policy if it's reopened later.

Scope, target, and upstream test all verified — with a minimal lockfile this is the right way to close #214.

[melekes]

Hi @huklaa, thanks for putting this together and for the clear write-up linking back to #214 and #227 — the suffix-gap context is really helpful.

We're going to close this for now. The malachite dependency is scheduled to receive a broader update as part of our upcoming v0.8 release, which will bring in the upstream suffix-gap fix (and several related changes) in one coordinated bump.

Thanks again for the contribution!