fix(validator): give each compose validator a distinct Golden secret share

[Dominik1999]

Summary

The insecure Golden storage-key fixture (scripts/testdata/insecure-golden-storage-key/) ships a single secret-share.wire, and compose/validator.yml mounts that same directory into all three validators, pointing each at the same secret-share.wire. So every validator boots holding the identical participant secret share.

With a 2-of-3 threshold key, recovery needs two shares from distinct participants. When all three validators hold the same share, any two collected shares are the same participant, and the Combiner rejects them — so threshold recovery of a stored record is silently impossible, even though each validator does correctly store its encrypted TransactionInputs.

I hit this bringing up the demo network against admin-private-record-share-rpc (#2407): listing records worked, each validator issued a share, but combining any two always failed because they were the same participant. Giving each validator a distinct share makes 2-of-3 recovery succeed end to end.

Changes

• Split the fixture into per-participant shares: validator-1/secret-share.wire, validator-2/secret-share.wire, validator-3/secret-share.wire, sharing one setup-context.wire and public-key-set.wire.
• compose/validator.yml: each validator now points MIDEN_VALIDATOR_STORAGE_KEY_SECRET_SHARE at its own validator-<n>/secret-share.wire.
• The top-level secret-share.wire is kept (identical to validator-1/secret-share.wire), so single-validator tooling — including the CI benchmark smoke test, which is left untouched — keeps working.
• Added an #[ignore]d test storage_key::tests::write_insecure_golden_fixture that regenerates all fixture files deterministically from the existing tests::values_for helper, so the fixture stays reproducible with the node's own code (same secp256k1 params, epoch 0909…).

The shared setup-context.wire/public-key-set.wire bytes are unchanged — the split only adds the two additional participants' shares that values_for(2) / values_for(3) already implied.

Testing

• cargo test -p miden-validator --lib storage_key::tests::write_insecure_golden_fixture -- --ignored regenerates the fixture; the existing operator_keys() path already validates all three shares against the shared public set.
• Verified end to end on the demo network (this branch's fixture + Add private recovery API for validated inputs #2407 admin API): three validators booted with distinct shares, a real benchmark transaction was stored encrypted in each, and combining validator 1's + validator 2's shares in the browser recovered the TransactionInputs. With the previous single-share fixture the same combine failed as below-threshold.

Changelog

[[entry]]
scope = "validator"
impact = "fixed"
description = "The docker-compose network now gives each validator a distinct Golden storage-key share, so 2-of-3 threshold recovery of stored transaction inputs works."

[huitseeker]

Makes sense to me, accepting to unblock.