fix(parser): always return altitude as a float

[danielebarbaro]

Problem

'altitude' => isset($parts[2]) ? (float) $parts[2] : 0,

7.7,45.8,12 gives 12.0, a float. 7.7,45.8 gives 0, an integer. Same key, type depending on the input.

The docblock right above it says otherwise:

/**
 * @return array{longitude: float, latitude: float, altitude: float}
 */

So PHPStan was being told float and the code was returning int, which is exactly the kind of thing static analysis is supposed to catch and could not, because the cast is inside a ternary it has no reason to doubt.

Found while documenting the return shapes for #20.

Effect on callers

• A strict comparison against 0.0 fails where the file omitted the altitude.
• json_encode() emits 0 rather than 0.0, so a GeoJSON payload diffed against a fixture is unstable depending on whether the source coordinates carried a third component.
• Anything typed on the documented shape was working with a wrong type.

Fix

: 0.0. Both occurrences, parsePointCoordinates() and parseLineStringCoordinates(), which had the same expression.

Tests

tests/AltitudeTest.php:

• altitude is a float on a Point and on every position of a LineString when the coordinate omits it
• altitude is a float, and equal to 12.0, when the coordinate declares it
• the float survives into the GeoJSON position array, which comes out as exactly [7.7, 45.8, 0.0]

Suite 62 to 65. PHPStan and Pint clean.

Breaking change

Only in the sense that 0 === $altitude no longer holds and json_encode() now writes 0.0 where it wrote 0. Both are the documented behaviour rather than a change to it, but a strict test fixture somewhere could notice, so it belongs in the changelog and in the next major rather than in a patch.