chore: force usage of constructor for PermanentKeyshareData

[gilcu3]

Closes #1217

The issue was expanded to cope with ( see the comments below):

Unfortunately, this PR isn't helping in decoupling the node and the contract behavior.
Ideally, we want to get rid of the assumption that keyshares stored on the node follow the same order with which they are stored in the contract, and that the resharing of keys happen in the exact same order in which the keys are stored in the KeyshareStorage.

[claude]

Code Review

Clean encapsulation PR that makes PermanentKeyshareData fields private and routes all access through getters and the validated new() constructor. All call sites are mechanically updated.

No critical issues found.

Minor note (non-blocking): from_legacy and Deserialize both bypass the new() constructor's consistency validation. from_legacy is fine since a single keyshare trivially satisfies ordering invariants. The Deserialize bypass is pre-existing and necessary for loading persisted data, but worth being aware of if the invariants ever become more complex.

✅ Approved

[kevindeforth]

Unfortunately, this PR isn't helping in decoupling the node and the contract behavior.

Ideally, we want to get rid of the assumption that keyshares stored on the node follow the same order with which they are stored in the contract, and that the resharing of keys happen in the exact same order in which the keys are stored in the KeyshareStorage.

[claude]

PR title type suggestion: This PR restructures how PermanentKeyshareData is accessed (making fields private, enforcing constructor usage), which is refactoring—not just routine maintenance. Since source code files are changed, the type prefix should probably be refactor: instead of chore:.

Suggested title: refactor: force usage of constructor for PermanentKeyshareData

[claude]

Code Review

Clean PR that removes the implicit ordering assumption between permanent keyshares and contract keysets, replacing prefix-based matching with order-independent domain_id-based matching. All keyshares are now sorted by domain_id as the canonical order.

No critical issues found.

✅ Approved

[kevindeforth]

Thank you, only nits!

[claude]

PR title type suggestion: This PR refactors code to enforce constructor usage for PermanentKeyshareData, which is a structural change. Consider using refactor: instead of chore: to be more precise.

Suggested title: refactor: force usage of constructor for PermanentKeyshareData

[claude]

PR title type suggestion: This PR restructures code to enforce constructor usage, which is a refactoring effort. The type prefix should probably be refactor: instead of chore:.

Suggested title: refactor: force usage of constructor for PermanentKeyshareData

[kevindeforth]

Thank you!

[claude]

PR title type suggestion: This PR restructures code to enforce constructor usage for PermanentKeyshareData. The type prefix should probably be refactor: instead of chore:

Suggested title: refactor: enforce constructor usage for PermanentKeyshareData

[netrome]

No blockers spotted, but it feels like a lot of the logic would end up much cleaner if we used e.g. a BTreeSet for the keyshares (along with an appropriate Ord implementation)