Sample: Align isOperator and CanOperatorPass checks

[cjen1-msft]

In the sample constitution it was possible for an operator to add a new operator with a recovery key.

Specifically isOperator == !has_recovery_key && data.is_operator while canOperatorPass == data.is_operator.

Thus an operator could add an operator who has a recovery key, which is fine for canOperatorPass, but is not an operator for membership counting reasons.
So an operator could use this to add N+1 'operator recovery members' and hence pass their own ballots.

This PR aligns these two constraints.

To clarify this just fixes up a sample, not anything which is released.

[Copilot]

Pull request overview

This PR fixes an authorization/counting mismatch in the sample operator constitution by ensuring that “operator-only” proposals cannot add a member flagged as an operator while also assigning them a recovery (encryption) public key, which would otherwise exclude them from operator counting and allow vote-inflation.

Changes:

• Tighten canOperatorPass() for set_member so it only treats adding/setting an operator as “operator-passable” when encryption_pub_key is not provided (== null).
• Aligns the canOperatorPass eligibility criteria with isOperator()’s “operators cannot be recovery members” rule.

Custom instructions used:

• .github/copilot-instructions.md
• .github/instructions/reviewing.instructions.md

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.