Fix validate owner spec

[mariaKt]

This PR addresses a discrepancy between the signer-checking in validate_owner spec and the implementation's behavior, which utilizes an array of matched[MAX_SIGNERS] for deduplication.

This was found during 3-signer proof testing. With 1 tx_signer (all existing tests) the discrepancy is not observable; it only manifests when multiple tx_signers share the same key as a registered signer.

The implementation's validate_owner uses a single loop over tx_signers and registered keys with a matched[position] array. When a tx_signer's key matches a registered key at position p, it first checks !matched[p] — if the position was already claimed by a previous tx_signer, the match is skipped entirely (including the is_signer check). This means an unsigned tx_signer whose key matches an already-claimed position is silently ignored.

The spec's inner_test_validate_owner used two separate loops: unsigned_exists (outer tx_signers, inner registered keys) checked if any tx_signer matched a registered key while unsigned, and signers_count (outer registered keys, inner tx_signers) counted signed matches. Neither loop had matched[position] deduplication. With multiple tx_signers sharing the same key as a registered signer, the spec could detect an unsigned match on a position already claimed by a signed tx_signer — a scenario the implementation intentionally skips.

Fixed by replacing both loops with a single loop matching the implementation's structure: outer tx_signers, inner registered keys, with matched[position] to prevent double-counting and skip unsigned detection on already-claimed
positions. The same applies to expected_validate_owner_result, which has been addressed equally.

[mariaKt]

This seems like an obvious fix, but I would like to know if there is reason not to do it, i.e., the spec was intentionally written with two loops, one for the unsigned_exists check and one for the signers_count. So:

• if so, what was that reason? Was there a reason other than clearly identifying the cases of unsigned_exists and not enough signers?
• it seems that we cannot maintain the two independent loops. We need to either use the same loop structure, or use two loops but add an array like matched[MAX_SIGNERS] in which we "count" (set to true), and then use the second loop to gather the boolean values into in integer. If you prefer, I am happy to try this instead.

[dkcumming]

We had a call where we discussed the previous version versus this version. The previous version ran into trouble with duplicate signers (same Pubkey) where K symbolic state does not know that the same Pubkey implies that the rest of the Account is the same. Therefore, it was creating branches where two symbolic accounts sharing the same Pubkey could simultaneously have signed or not signed. There is a way to link these accounts (e.g. maybe_link_accounts) but this is likely overkill for now.

Using the approach in this PR programmatically enforces the necessary condition as it will record in the array if the Pubkey is seen already, and skip the error.