Since 2d indexes do not "wrap" (like how +180 and -180 longitude are the same on a sphere), we have to be careful that we do not treat the minimum and maximum bounds the same for a 2d index. We handle this when generating the geo hash as a special case when the value == the maximum bounds, by slightly decrementing the value (treating 180, for example, as 179.9999) before scaling it to compute the relevant geo index bucket for the key string.

If the input value is not quite the maximum but very close, we may reach a case of undefined behavior. We've seen that in some cases, convertToDoubleHashScale may return 4,294,967,296, which is exactly the number of geo buckets we have (0-indexed). Once we cast that value to an unsigned int, we reach undefined behavior: depending on the architecture, it will either truncate to 4,294,967,295 (which is the value we'd hope for, indicating the maximum bounds geo bucket), or max overflow to 0 (which would treat it as if the index "wrapped" back around to the minimum bounds, incorrectly). In my local testing, I only observed the more ideal behavior, maintaining query correctness.