fix(types)!: reject malformed SignedOrder JSON at deserialize time

[prestwich]

Summary

• Fix ENG-2288: SignedOrder::order_hash() panicked on a SignedOrder deserialized from untrusted JSON whose signature was not exactly 65 bytes — an asymmetric DoS vector against any consumer of the tx-cache order feed.
• Promote structural invariants (signature length, non-empty permitted, non-empty outputs) to type-system guarantees enforced at deserialize time, so order_hash's Signature::from_raw(...).unwrap() becomes sound by construction.
• Reusable signet_zenith::serde_helpers exposes deserialize_signature_bytes and deserialize_non_empty_vec for other sol-shaped types that need the same treatment at JSON boundaries.
• Rename SignedOrder::new → new_unchecked (documenting the invariants the caller must uphold) and SignedOrder::validate → validate_at, plus a new is_valid_at, drawing a clear line between structural validity (enforced at construction) and time/state validity (checked at call sites).
• Proptests in signet-test-utils/tests/deserialization_fuzz.rs prove the SignedOrder deserialize path is total — every input either deserializes into a value satisfying all three invariants, or errors via serde; never panics.
• // SAFETY: annotations on two audit findings (agg/fill.rs:209, agg/order.rs) whose unwraps/casts are sound under caller-side or protocol invariants.

Breaking changes

• SignedOrder::new(...) → SignedOrder::new_unchecked(...)
• SignedOrder::validate(...) → SignedOrder::validate_at(...)
• <SignedOrder as Deserialize> now rejects inputs that previously deserialized successfully (i.e. the bug).

Minor-version bump recommended on next release.

Reporter

This bug was reported externally by Cinder Circuit / @achimala under the Signet bug bounty.

Test plan

• cargo t -p signet-types -p signet-zenith -p signet-orders -p signet-test-utils — all pass
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo clippy --workspace --all-targets --no-default-features -- -D warnings
• RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps
• cargo +nightly fmt -- --check
• Reproduction test for the bounty bug flipped from #[should_panic] to asserting a serde Err
• Proptest coverage: helper boundaries, SignedOrder totality, round-trip stability, garbage-string safety
• Reviewer to confirm tx-cache stream consumers surface deserialize errors gracefully rather than terminating the stream when a malformed order arrives

🤖 Generated with Claude Code

Fixes ENG-2288

[Fraser999]

One blocker on the issue in checked_remove_aggregate.

[Fraser999]

Suggested change

	fn non_empty_vec_rejected() {
	fn empty_vec_rejected() {

[Fraser999]

Claude has spotted that this isn't really true. The following snippet probably explains the edge case best:

let mut context = AggregateFills::default();
let asset = Address::with_last_byte(1);
let present_recipient = Address::with_last_byte(99);
let missing_recipient = Address::with_last_byte(2);

// The outer `(chain, asset)` key exists in `self.fills`, but only `present_recipient` is in the inner map.
context.add_raw_fill(1, asset, present_recipient, U256::from(100));

// Zero-amount output to a recipient that is absent from `self.fills[(1, asset)]`.
// `check_aggregate` returns `Ok` here.
let mut aggregate = AggregateOrders::new();
aggregate.ingest_raw_output(1, asset, missing_recipient, U256::ZERO);

// Sanity check: the prior check the SAFETY comment leans on is currently a no-op for this input.
context.check_aggregate(&aggregate).unwrap();

// The unwrap inside `checked_remove_aggregate` panics here.
let _ = context.checked_remove_aggregate(&aggregate);

We probably want to tighten check_aggregate to fail for this case (and add a regression test)?