Fix: ReverseGeocoder sends coordinates near zero in scientific notation, rejected by Nominatim

[DeanTheProgrammer]

ReverseGeocoder.buildQueryString converts the Latitude/Longitude values from ReverseGeocodeRequest to strings using a bare .ToString(CultureInfo.InvariantCulture.NumberFormat) call, without an explicit numeric format specifier. .NET's default ("G") format switches to scientific/exponential notation for values close to zero (e.g. 0.0000093 becomes "9.3E-06").

This affects any coordinate close to the equator (latitude ≈ 0) or the prime meridian (longitude ≈ 0). A concrete repro is the Prime Meridian marker at the Arora Ballroom & Conference Centre, Greater London: lat=51.5028298, lon=0.0000093. The lon value gets serialized as "9.3E-06", which the Nominatim HTTP API does not accept as a valid coordinate, resulting in a failed or incorrect request.

Pre-formatting the double before constructing the request has no effect, since Latitude/Longitude are stored as raw double? and re-converted to string internally by the library — any caller-side formatting is discarded.

Fix: format Latitude/Longitude with an explicit fixed-point format string (e.g. "0.0000000") instead of the default ToString(), so coordinates near zero are always serialized in decimal notation.

Test added: ReverseGeocoderTests.ReverseGeocodeAsync_NearPrimeMeridian_DoesNotSendCoordinatesInScientificNotation, using the Greenwich coordinates above and a mocked INominatimWebInterface to assert the outgoing query string never contains scientific notation for lat/lon.