fix(validator): reject a manifest that reuses one key for both signing roles

[adust09]

Summary

ValidatorEntry documents that the attestation and proposal keys are separate "so one validator can sign both within the same slot without OTS conflict" — but nothing enforced it. The registry loader assigned keys without comparing them, and from_yaml never compared the two keys it loaded. A node whose manifest carried the same key in both fields signed a block proposal and an attestation for the same slot with the same stateful XMSS key — the one-time-signature state reuse the separation exists to prevent — and nothing surfaced it.

With identical key material in both fields, each signing path advanced its own field's copy from the pre-advance state, so the two signatures consumed overlapping OTS state (a key-compromise-class failure for hash-based schemes). Both loads succeeded and both signatures verified individually, so the misconfiguration stayed invisible.

Fix

Reject the misconfiguration at load time by comparing the manifest's two public keys, which leaves the secret bytes untouched and fires before any key file is decoded. This turns the docstring invariant into a client-checkable rule and discharges the formal model's WellFormed distinctness assumption at construction — the same shape as #1179 did for the store invariants.

Real manifests are unaffected: production key generation derives the attestation and proposal keypairs from two independent key_gen calls, so their public keys always differ.

Testing

• Added test_same_key_for_both_roles_raises, which asserts the full error message and writes no key files, proving the check fires before any decode.
• Updated the shared manifest-entry test helper so its two public keys differ, as the loader now requires.
• uv run pytest tests/node/validator/ — 78 passed.
• ruff lint + format, ty typecheck, codespell all pass.

Closes #1184