[Sunhy (Shy7777)]

Motivation & Context

An in-memory Hamming search can report an exact match for two different 64-bit integer vectors. For example, [2**53, 0] and [2**53 + 1, 0] both receive a distance of zero because their coordinates are converted to floats before comparison. This also lets the wrong record through a zero-distance threshold.

Description & Review Guide

• What are the major changes? Keep integer coordinates intact during numeric validation and compare them directly for Hamming distance. Arithmetic distance metrics retain their floating-point conversion.
• What is the impact of these changes? Signed and unsigned 64-bit vectors get the correct Hamming scores, ordering, and threshold filtering. The six new regression cases and the existing in-memory/vector tests pass: 393 tests in total.
• What do you want reviewers to focus on? The integer comparison happens before any lossy conversion, while the existing vector validation and arithmetic metric behavior remain in place.

Related Issue

Fixes #8636

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

The full repository unit suite was not run; the local test run covered the two related suites above.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Eduard van Valkenburg (eavanvalkenburg)]

Sunhy (@Shy7777) Reviewed the complete diff; no high-confidence issues found.