Fix bisector non-termination on arrays larger than 2³¹ elements

[maximilliangrand]

Problem

bisector computes the midpoint as (lo + hi) >>> 1. >>> coerces its operand to a Uint32, so once lo + hi reaches 2³² the sum wraps and the midpoint lands outside [lo, hi). The interval stops narrowing and the loop never terminates — it freezes the tab in Safari, which allows arrays this large. This is #261, confirmed there with new Uint8Array(2147483649); d3.bisectRight(a, 0).

Repro (no giant allocation needed — a Proxy stands in for a sorted array of ~2³² zeros; a correct bisect reads ≤ log2(len) ≈ 32 elements):

let reads = 0;
const a = new Proxy({}, {get(_, k) {
  if (k === "length") return 2 ** 32 - 1;
  if (++reads > 64) throw new Error("did not converge");
  return 0;
}});
bisectRight(a, 0); // never converges before the fix

Fix

Use Math.trunc((lo + hi) / 2) — the form @mbostock proposed in #261 and @yurivish agreed to. It only loses precision once lo + hi reaches 2⁵³ (≈9 PB of indices), far beyond any array a browser can allocate, so it is strictly more robust than the lo + (hi - lo >>> 1) alternative. Same integer arithmetic, no measurable cost. This is the only >>> 1 midpoint in src (quickselect uses Math.floor).

The added regression test passes with the fix and fails without it (the loop reads past 64 elements and throws).

A note on scope

Fil raised an open question in the issue: whether d3 wants to officially support arrays this large, versus documenting a supported cap of ~2³⁰ elements. This PR is the minimal, zero-cost fix — it removes the non-termination without committing the project either way, and the call on documenting a limit is left to the maintainers.

Closes #261.