Resolve "Bug: change_owner_key autorise des identités Unconfirmed, Unvalidated et Revoked"

⚠️ Breaking changes ⚠️

identity.change_owner_key now rejects identities in Unconfirmed and Revoked status.

Integrators and tooling that assumed change_owner_key could be submitted for any existing identity should update that assumption. In particular:

• calls for Unconfirmed identities now fail at runtime,
• calls for Revoked identities now fail at runtime,
• Unvalidated, Member, and NotMember identities remain allowed.

Goal of the changes

Prevent change_owner_key from being used on identity states where changing the owner key is not a valid operation, while preserving the existing behavior for identities that are still expected to progress through the v2 lifecycle.

What reviewers need to know

The runtime now adds an explicit status gate in pallet_identity::change_owner_key:

• Unconfirmed => rejected,
• Revoked => rejected,
• Unvalidated => allowed,
• Member => allowed,
• NotMember => allowed.

Two dedicated pallet errors were introduced so the rejection reason is explicit:

• CanNotChangeOwnerKeyOfUnconfirmed
• CanNotChangeOwnerKeyOfRevoked

The test suite was extended to cover:

• refusal for Unconfirmed,
• refusal for Revoked,
• success for Unvalidated,
• success for NotMember,
• regression coverage for the existing Member path.

Additional pruning coverage was added for Unvalidated identities to verify that an identity which is never validated is still removed at the validation deadline, both:

• without any key change,
• after a successful change_owner_key.

This is important because migrated Unvalidated identities can still rotate their owner key, but that key change must not interfere with scheduled cleanup.

Testing

cargo test -p pallet-identity test_change_owner_key cargo test -p pallet-identity unvalidated_identity_is_pruned

Closes #360 (closed)