Align HyperLogLog add() bit handling with Spark

[sleeepyjack]

Closes #696

Summary

• Align HyperLogLog register selection and leading‑zero computation in add() with Spark’s
  HyperLogLog++ helper logic.
• Fix a leading‑zero discrepancy that could shift estimates by 1 for small sketches (e.g.,
  standard_deviation=0.3, precision p=4).
• Align bias interpolation anchor selection with Spark (use insertion‑point anchor for bias
  correction rather than “closest” entry).

Changes

• Register index: Use the top p bits of the hash (h >> (bits - p)) to select the register,
  matching Spark’s idx = x >>> (64 - p).
• Leading zeros: Compute leading zeros on the remaining bits using Spark’s padded approach:
  clz((h << p) | (1 << (p - 1))) + 1. The padding bit prevents the shifted value from becoming
  all‑zero, which would otherwise inflate the zero count.
• Bias anchor: Use Spark’s insertion‑point anchor for bias interpolation (the index returned
  by binary search when no exact match exists). cuco previously snapped to the nearest neighbor,
  which shifts the low..high bias window by one entry and can move the rounded estimate by 1.

The previous implementation mixed low‑bit register indexing with a different zero‑count scheme.
When the remaining bits were all zero after shifting, clz(h << p) + 1 could over‑count leading
zeros relative to Spark’s (h << p) | wPadding method. This mismatch changes the register values
and can bias the final estimate by a small amount. Using Spark’s MSB‑based index and padded
leading‑zero count brings cuco’s results in line with Spark for the reported reproducer.

[PointKernel]

@sleeepyjack can you please add a unit test to excercise this res matching?

[sleeepyjack]

@res-life would you mind running your Spark experiments with the updated cuco HLL to see if this PR fixes the issue?