fix: use nextOwnerIndex instead of ownerCount in findOwnerIndex

[stephancill]

Summary

findOwnerIndex used ownerCount() to bound its iteration over owner slots. However, ownerCount = nextOwnerIndex - removedOwnersCount, which means it skips owners at higher indices when previous owners have been removed.

For example, a sub-account with nextOwnerIndex=15 and removedOwnersCount=13 reports ownerCount=2, so findOwnerIndex only checks indices 0-1 — missing the owner at index 14. This causes a false negative, triggering an unnecessary reauthorization flow that attempts addOwnerPublicKey and reverts onchain with AlreadyOwner.

The fix changes the iteration bound from ownerCount() to nextOwnerIndex(), ensuring all owner slots (including those at high indices after removals) are checked. Empty slots from removed owners return 0x and are naturally skipped by the comparison.

How did you test your changes?

• Existing unit tests updated (comments changed from ownerCount to nextOwnerIndex)
• Added new test case: finds owner at high index when previous owners have been removed
• All 11 tests pass
• Verified against a real production sub-account (0x463f3D229E2fe046807d189CCD0cE9758851f10b) on Base where this exact bug was occurring

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 2/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[github-actions]

PR Title: valid (fix: ... conventional commit format)

Summary: Clean, well-targeted bug fix. No issues found.

The change from ownerCount() to nextOwnerIndex() is correct — ownerCount excludes removed owner slots, causing the loop to miss owners at higher indices. nextOwnerIndex is the monotonically increasing high-water mark, so iterating [0, nextOwnerIndex) covers all allocated slots. Removed slots return 0x and are naturally skipped by the case-insensitive comparison.

• Correctness: Verified nextOwnerIndex exists in the contract ABI (constants.ts:282). The iteration logic is sound.
• Type safety: No new as casts or any types. Number(nextOwnerIndex) is safe for realistic owner counts.
• Test coverage: New test case directly exercises the bug scenario (owner at high index with removed intermediate slots). Existing tests updated with corrected comments.
• API surface: No public API changes — findOwnerIndex signature and return type are unchanged.
• Bundle impact: None — no new dependencies or code paths.

[spencerstock]

LGTM - looks pretty straightforward. Thanks for fixing.