Use BuildResult for init proof signing

[nkryuchkov]

Summary

Fix the init-path proof signing mismatch in dkg-spec.

Operator.Init() was signing ceremony proofs with proof.MarshalSSZ(), while both BuildResult() and VerifyCeremonyProof() use proof.HashTreeRoot(). That meant anyone following the stubbed Init() implementation as the operator reference would produce proofs that fail verification.

This change refactors Operator.Init() to call BuildResult() directly, so init/reshare/resign all share the same result-building and proof-signing path.

Changes

• Refactor Operator.Init() to delegate to BuildResult()
• Remove duplicate init proof-signing logic
• Add a regression test showing:
  • HashTreeRoot()-signed proofs verify
  • MarshalSSZ()-signed proofs do not verify

[nkryuchkov]

@greptileai please review this PR

[y0sher]

small comment.

[iurii-ssv]

Looks reasonable, but we really need repo maintainers to approve before merging

[ljuba-ssv]

Correct fix — eliminates the duplicate code path by delegating to BuildResult(). All three operator paths (Init, Reshare, Resign) now share the same signing logic. Regression test is well-designed. Net -29 lines.

[MatheusFranco99]

LGTM!
One small thing: I see that BuildResult is tested, but not Operator.Init itself, idk if it's relevant though

[nkryuchkov]

LGTM! One small thing: I see that BuildResult is tested, but not Operator.Init itself, idk if it's relevant though

I didn’t add a direct Operator.Init test because Init() is still a stub around the ceremony and doesn’t produce a real share/validator pubkey on its own. Since this change is specifically about the proof-signing path, I covered that at the shared implementation point (BuildResult) and with TestVerifyCeremonyProofSignaturePath, which checks the exact MarshalSSZ() vs HashTreeRoot() mismatch.