feat(core): encode/decode UnsignedDataSet proto for all duty types

[emlautarom1-agent]

Summary

Implements the all-duty-type UnsignedDataSet protobuf codec in pluto-core, so unsigned duty data for every duty type can be carried over the consensus wire and decoded by peers.

What it implements

• unsigned_data_set_to_proto(&UnsignedDataSet) -> Result<pbcore::UnsignedDataSet, ParSigExCodecError> — encodes attester, proposer, aggregator, and sync-contribution unsigned data.
• unsigned_data_set_from_proto decoding for proposer, aggregator, and sync-contribution duty data (attester was already supported).
• SSZ encode/decode helpers in ssz_codec for the unsigned VersionedProposal, VersionedAggregatedAttestation, and SyncContribution.

The encoding is SSZ-first with a JSON fallback on decode, matching Charon's UnsignedDataSet wire format so a Pluto node interoperates with Charon nodes in a mixed-client cluster.

The JSON-fallback path reuses the existing versioned deserializers in signeddata instead of duplicating the per-fork dispatch: VersionedAggregatedAttestation decodes through VersionedAttestation's Deserialize, and a new Deserialize for VersionedProposal is added beside its signed sibling (sharing the VersionedRawBlockJson wrapper). The looks_like_json prefix check is shared with parsigex_codec. As a result the diff also touches signeddata.rs and parsigex_codec.rs.

Ports charon/core/proto.go + core/unsigneddata.go. Part of #402.

Testing

Round-trip (encode → decode) unit tests for all four duty types, plus the non-versioned aggregator and JSON-fallback decode paths.

[emlautarom1]

@claude

[claude]

Claude finished @emlautarom1's task in 3m 44s —— View job

---

Code Review: UnsignedDataSet proto codec

• Read the PR diff (unsigneddata.rs, ssz_codec.rs, signeddata.rs, parsigex_codec.rs)
• Cross-check against Charon Go source (core/proto.go, core/unsigneddata.go, core/ssz.go)
• Review correctness, style, and tests
• Post review feedback

Overall this is a careful, well-documented port. The doc-comments that explain why the layout matches Charon (the hand-rolled attester offset table, the SSZ-first/JSON-fallback rationale) are excellent and make the parity easy to verify. Functional equivalence with Charon checks out across the board. I have one substantive concern about test coverage and a few minor notes.

---

🟠 Main concern — the Deneb/Electra/Fulu BlockContents SSZ layout is untested

The most novel, highest-risk code in this PR is the two hand-declared containers in ssz_codec.rs:

• DenebBlockContents (crates/core/src/ssz_codec.rs:599)
• ElectraBlockContents (crates/core/src/ssz_codec.rs:610)

These are brand-new structs whose byte layout must match Charon's eth2deneb.BlockContents / eth2electra.BlockContents exactly for cross-client interop — but no test exercises them:

• The proposer round-trip (round_trip_proposer) and the proposer JSON-fallback test both use sample_versioned_proposal_phase0 only (unsigneddata.rs:525). Phase0 never goes through DenebBlockContents/ElectraBlockContents.
• Unlike the signed codecs, the new unsigned types have no Go golden-vector fixtures under crates/core/testdata/ssz/ (the existing go_fixture_* tests at ssz_codec.rs:1137+ only cover signed/attestation types).

The consequence: a field-order or offset bug in the block-contents layout (the exact failure mode the doc-comment at ssz_codec.rs:587 warns about for the attester case) would pass every test in this PR while silently breaking interop with Charon nodes for Deneb+ proposals — which is essentially every proposal on mainnet today.

Two suggestions, ideally both:

1. Add a Deneb (and Electra) round-trip case to round_trip_proposer so the new containers are at least exercised end-to-end within Pluto.
2. Add Go golden-vector fixtures for an unsigned Deneb VersionedProposal, a VersionedAggregatedAttestation, and a SyncContribution, mirroring the existing go_fixture_versioned_proposal_phase0 pattern. This is what actually proves charon wire-compat for the new types.

Add Deneb/Electra round-trip + Go golden fixtures for unsigned types →

---

🟡 Minor

• Unbounded blob/proof lists on decode — DenebBlockContents/ElectraBlockContents use plain Vec<deneb::KZGProof> / Vec<deneb::Blob> (ssz_codec.rs:601-602, 612-613). Charon's fastssz enforces the MAX_BLOBS_PER_BLOCK / commitment list bounds on decode; a derived Vec does not. Wire bytes round-trip fine, so this isn't an interop bug, but a peer could send an over-length list that decodes successfully here. Worth a comment noting bounds are enforced upstream (or adding a length check) if the p2p message-size cap isn't considered sufficient.

• looks_like_json evaluated twice — decode_versioned_proposal (unsigneddata.rs:161 & 167) and decode_sync_contribution (unsigneddata.rs:226 & 232) call looks_like_json(data) twice. Minor; a single let is_json = looks_like_json(data); reads cleaner. (The attester path at unsigneddata.rs:242 already avoids this by trying SSZ unconditionally first, which is also the closest match to Charon's unmarshal.)

• Documented ordering divergence (no action needed) — Charon's unmarshal (core/proto.go:287) always attempts SSZ first, then JSON only if the { prefix is present. The short-circuit form here (skip SSZ when looks_like_json) is functionally equivalent because a {-prefixed buffer can't be a valid versioned-SSZ header (first byte 0x7B ⇒ invalid DataVersion). Just flagging it's an intentional, safe reordering rather than a literal port.

---

✅ Verified against Charon

• Header sizes match core/ssz.go constants: proposal version(8)+blinded(1)+offset(4)=13, aggregate version(8)+offset(4)=12 (versionedBlindedOffset/versionedOffset, ssz.go:636).
• Aggregator decode reproduces Charon's two-stage fallback: versioned → non-versioned AggregatedAttestation (raw phase0), for both SSZ and JSON paths (unsigneddata.rs:184 vs unmarshalUnsignedData unsigneddata.go:674).
• Deserialize for VersionedProposal faithfully mirrors VersionedProposal.UnmarshalJSON (unsigneddata.go:490), including the pre-merge-blinded rejection and Deneb+ BlockContents {block, kzg_proofs, blobs} shape with optional/null-tolerant fields.
• Electra/Fulu aggregated attestations correctly route through electra::Attestation (committee bits), matching VersionedAggregatedAttestation.sszValFromVersion (ssz.go:619).
• SyncContribution is a bare altair::SyncCommitteeContribution with no versioned header, matching core/unsigneddata.go:618.
• Block values (consensus_block_value/execution_payload_value) correctly dropped from the wire and defaulted to zero on decode, as in Charon.
  · branch emlautarom1/core-unsigned-proto-codec

[emlautarom1]

Manually checked, LGTM. The serialization/deserialization code is just messy by nature due to this JSON/SSZ split.