fix(types): make malachitebft-signing-ed25519 a required dependency

[mehmetkr-31]

Fixes #236.

Summary

arc-consensus-types does not build with --no-default-features:

$ cargo check -p arc-consensus-types --no-default-features
error[E0432]: unresolved import `malachitebft_signing_ed25519`
  --> crates/types/src/proposal_part.rs:26:5
  --> crates/types/src/codec/proto.rs:28:5
  --> crates/types/src/signing.rs:21:9
  --> crates/types/src/ssz/v1/vote.rs:21:5

The signer-local feature gated dep:malachitebft-signing-ed25519, but those four modules import it unconditionally and feature = "signer-local" never appears in a #[cfg] anywhere in the workspace. The feature offered no real choice — with it the crate builds, without it the build breaks on unresolved imports.

Change

Make the dependency required, and drop signer-local together with the now-empty default. No crate in the workspace requested the feature explicitly, so nothing needs updating alongside this.

Testing

• cargo check -p arc-consensus-types --no-default-features — now compiles (fails on main).
• cargo check --workspace --all-features — passes, no regression.
• cargo test -p arc-consensus-types — 192 tests pass.
• cargo fmt --all --check — clean.
• Cargo.lock unchanged.

Two things worth your call

Feature-name compatibility. Removing the name means an external consumer spelling features = ["signer-local"] would hit an unknown-feature error — though no such consumer can exist today, since the crate does not build without it. If you would rather keep the spelling working, signer-local = [] as a no-op alias gives the same fix; I am happy to switch. A third option is keeping the feature and adding a compile_error! guard the way arc-signer does, which turns the failure into a readable message but leaves a flag that can only ever be on.

Overlap with #231. That PR also edits the [features] table in crates/types/Cargo.toml (it declares the arbitrary feature's own dependencies, per #233). The two changes are independent and touch adjacent lines, so whichever lands second may need a trivial rebase — I will handle it, just let me know if you would prefer them combined into one PR instead.

[osr21]

Reviewed the diff against the verification I did on #236 — this is the right resolution and the mechanics are complete:

• The dependency edit is behavior-preserving for every existing consumer: previously all in-workspace consumers got the dep via default = ["signer-local"] (nobody used default-features = false on this crate); now they get it unconditionally. Same compiled graph, same ["rand", "serde"] features on the dep — which is why Cargo.lock is untouched, and that untouched lockfile is itself evidence the change only moves declarations, not resolution.
• Dropping the now-empty default rather than leaving default = [] is right — an empty default table is noise that invites someone to wonder what used to live there. Git history answers that better.

On the two calls you flagged:

1. Removal without the alias — as argued in more detail on #236, the no-op alias protects a consumer class that provably cannot exist. Any external crate spelling features = ["signer-local"] necessarily also compiled the four unconditional imports, which only ever built with the feature on — so no one depends on the off-state, and the on-state is now simply the crate's permanent state. The compile_error! route is worse than both alternatives: arc-signer earns its guard by having a genuine either/or between providers, while a guard here would formalize a flag with exactly one legal value. One additional data point for the record that settles it beyond the build argument: signing.rs re-exports the dep's types (pub use malachitebft_signing_ed25519::{Ed25519, PrivateKey, PublicKey, Signature}), so the "optional" dependency's types were unconditionally part of this crate's public API all along. A feature cannot meaningfully gate a dependency the crate's API surface hard-requires — removal is the only honest declaration.

2. Keep the PRs separate; land #231 first if there's a choice. The two changes fix opposite halves of the same defect class (#233: feature-on doesn't build standalone; #236: feature-off doesn't build at all), and separate PRs keep each one revertible against its own issue. The rebase collision is one adjacent-line merge either way. Mild preference for #231 landing first only because its diff adds to the [features] table this PR shrinks — rebasing an addition over a deletion is marginally less error-prone than the reverse, and both are trivial.

Worth noting the verification here quietly demonstrates the gap #233's proposed cargo-hack CI job would close: --no-default-features per crate is now load-bearing correctness (this PR is the proof) and nothing in CI exercises it. If that job gets filed, this crate is the test case for both directions.

Approving — minimal, correct, and the feature table now tells the truth.