Improve sorting logic in NeighborArray and add test for stable order

[rajat315315]

Fixes #16321

Description

The legacy sorting logic in NeighborArray below takes O(N^2) in worst case, as it is a form of insertion sort and pushes/copies the rest of the array towards the end for each uncheckedIndex.

The solution I'm proposing takes O(N) time complexity and O(N) space complexity.

[rajat315315]

Benchmark Results

I ran luceneutil's KnnGraphTester to measure the impact of the NeighborArray.sort() optimization. The benchmark was executed on the SIFT1M dataset (128 dimensions) using the Java Vector API.

Test Parameters:

• maxDoc: 1,000,000
• maxConn: 16
• beamWidthIndex: 100
• numQueries: 10,000

Hardware/Environment:

• JDK Vector Incubator: Enabled (preferredBitSize=256; FMA enabled)

Metric	main (Baseline)	PR Branch	Difference
Index Time (CPU)	177.03s	172.71s	-2.4%
Index Time (Merge Wait)	91.72s	81.34s	-11.3%
Search Time (1k queries)	1,832 ms	1,660 ms	-9.3%
Search QPS	545	602	+10.4%

Conclusion:
Replacing the $O(N^2)$ insertion sort yields a measurable reduction in graph construction time and background merge overhead. We also see a ~10% throughput increase during the search phase.

[msokolov]

Can you explain the search speedup? I don't see how any improvements in this area can affect search given that we only use NeighborArray while indexing. This is making me doubt all the results reported here.