perf(indexing): speed up sorted 1-D coordinate selections

[selmanozleyen]

Summary

Speeds up CoordinateIndexer for sorted, in-bounds, one-dimensional integer selections on regular chunk grids.

Because the coordinates are already grouped by chunk, this uses searchsorted over the touched chunk boundaries instead of repeatedly processing the full selection.

Runs	Elements	main	This PR
1,024	1.48M	8.7 ms	0.5 ms
4,096	5.94M	35 ms	2.1 ms
8,192	11.9M	71 ms	4.5 ms

Closes #4170

Author attestation

• I am a human, these are my changes, and I have reviewed and understood every change and can explain why each is correct.

TODO

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs — not applicable; no public API changes
• Update the user guide — not applicable; behavior is unchanged
• Changes documented in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.90%. Comparing base (b213b54) to head (975a5f1).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4172      +/-   ##
==========================================
+ Coverage   93.89%   93.90%   +0.01%     
==========================================
  Files          91       91              
  Lines       12636    12665      +29     
==========================================
+ Hits        11864    11893      +29     
  Misses        772      772              

Files with missing lines	Coverage Δ
src/zarr/core/indexing.py	96.42% <100.00%> (+0.12%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[selmanozleyen]

I did another performance and boundary-condition pass and found two additional cases worth handling:

• The boundary after the last selected chunk could overflow np.intp. I changed the calculation to search only internal chunk boundaries and derive the first and last counts from the selection length.
• Sorted but very sparse selections could be slower because the new implementation enumerated every chunk between the first and last coordinates. I added a cost check based on chunk_span * log2(n) so these selections fall through to the existing implementation.

For a selection spanning one million chunks, this removes the regression:

	Time
New implementation before the guard	6.88 ms
Existing implementation	3.31 ms
With the guard	4.14 ms
Forced existing implementation in the same run	4.23 ms

The original large-gather workload still uses the new implementation by a wide margin. I also added regression tests for both cases.

Runs	Elements	Old CoordinateIndexer	Current implementation	Speedup
1,024	1.48M	10.36 ms	0.32 ms	32.3×
4,096	5.94M	49.15 ms	1.59 ms	30.9×
8,192	11.9M	97.59 ms	3.04 ms	32.1×

[d-v-b]

looks good, thank you!