Keep large ordered sequence indices as integers

[OskarEichler]

Summary

Return an integer position from find_ordered_index without applying sequence-number star conversion. Ordered entries may repeat, so their indices can reach 2**32 even though individual sequence numbers cannot. That integer currently becomes :*, breaking the index contract.

Reproduction

require 'net/imap'
set = Net::IMAP::SequenceSet['1:4294967294,1:2,4294967295']
p set.find_ordered_index(4294967295)
# before: :*; after: 4294967296
# Only three stored ranges are used; no huge array is expanded.

Verification

• 11 focused checks; two failing expectations before, zero afterward. Compact inputs exercise indices below/at/above 2**32, star entries, ordinary indices, absent numbers and the ordered_at inverse without enumerating large ranges.
• Existing rake test on this isolated branch: 1726 tests, 12592 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications, Ruby 4.0.6 via rbenv. The baseline also passes all 1,726 tests; assertion counts vary slightly across runs.
• Supplemental RuboCop Lint retains the same 48 existing findings. Ruby syntax and git diff --check pass. No repository tests, dependencies or workflows were added or modified; focused reproductions live outside the repository under the consumer's no-new-tests policy.
• Independent branch based on 6d2ef7a636a1e2449187a83b06ac7a5baa54ead2; the runtime diff from released 0.6.6 is documentation-only before this patch.

Compatibility and limits

No signature change. The affected boundary now returns its documented Integer index instead of a star Symbol. Actual sequence-number star conversion remains unchanged. Other Ruby/OS versions were not run locally. No production or external IMAP service was used. Local verification does not imply upstream CI approval or comprehensive behavioral coverage.

[nevans]

Please add a test.

Keep it fast by using a small number of large ranges. Too many elements will make it too slow. The example in the description is perfect.

That said, an index larger than UINT32_MAX is of very low practical value. It's far more likely to be abused than used intentionally. We may want to impose some limit on the maximum. But don't worry about that for this PR.

Although there's no risk of going over UINT32_MAX, #find_index also shouldn't use #export_num.