Fix integer overflow in geographic distance features

[aalquwayfili]

GeoDistanceFeatures can produce incorrect Euclidean and Manhattan distances when coordinate columns use narrow or unsigned integer dtypes. For example, the valid uint8 coordinates (1, 2) and (0, 1) produce approximately 40,029 km instead of 157 km with the Euclidean method. Signed integer overflow can also produce a negative Manhattan distance.

Compute coordinate differences in floating point before subtraction, so neither the differences nor their Manhattan sum overflow. The regression covers unsigned subtraction, signed subtraction, signed addition, both route directions, and a floating-point control; the original coordinate columns retain their dtypes and values.

Validation: all 192 creation tests pass, including the 8 regression cases and the existing pipeline checks. Targeted Flake8, mypy, and isort checks pass.

The subtraction now computes in float64. The full-project mypy check reports two errors in unrelated files; its output is identical on the unmodified base. Repository-wide tests and documentation rendering were not run.

Upstream CI: all Python 3.10–3.14 test configurations, documentation, style and typing pass. The Python 3.9 job has the same 52 failing estimator-check IDs and exception summaries as the exact unmodified base; its passed-test count increases from 2,065 to 2,073 with the eight new cases.