DfsuBuilder writes a metre quantity for X/Y static items even in geographic projections (disabled block at DfsuBuilder.py:524)

`mikecore/DfsuBuilder.py:521-528` sets the quantity used for the `X-coord` and `Y-coord` static items, with the geographic case commented out:

```python
xyQuantity = eumQuantity(eumItem.eumIGeographicalCoordinate, eumUnit.eumUmeter)

# TODO: reenable:
#if (MapProjection.IsValid(self.__dfsProjection.WKTString)):
# if (MapProjection.IsGeographical(self.__dfsProjection.WKTString)):
# xyQuantity = eumQuantity(eumItem.eumILatLong, eumUnit.eumUdegree)
```

As it stands, every dfsu written by `DfsuBuilder` gets `eumIGeographicalCoordinate` in metre for its X/Y static items — including files whose projection is geographic. For a `LONG/LAT` file the coordinates in those items are degrees, so the recorded unit is wrong: the disabled block is exactly what would have set `eumILatLong`/`eumUdegree` instead.

Reproduction: build a dfsu with `SetProjection` given the `LONG/LAT` WKT, write it, then read back the `X-coord` static item and inspect its quantity — it reports metre.

`Projections.py` already exposes the projection-inspection needed to re-enable this, so the question is whether the block was disabled for a reason (a dependency that was not ported, or a deliberate compatibility choice) or simply left behind. Not fixed here — writing a different quantity into files changes output, and that decision should be explicit.

Start at mikecore/DfsuBuilder.py:521-528 and inspect the projection helpers already exposed in Projections.py. Reproduce the LONG/LAT case described in the issue, then determine whether the disabled geographic-quantity block was intentional or left behind. Done means the compatibility decision is explicit and the X/Y static-item quantity behavior is verified against that decision.

Written by the indexing model from the issue text.