Fix misleading geo_to_ht docstring (geoid vs. WGS-84) and clarify DEM datum in AOI docs

[jlmaurer]

Summary

The geo_to_ht docstring in utilFcns.py claims its output is referenced to the WGS-84 ellipsoid, but the function actually returns geometric height above the geoid (≈ mean sea level). The computation is correct; only the docstring is misleading. While looking into this, a related documentation gap around DEM vertical datums came up that should be checked with the llreader.py module to ensure DEM height datums are handled correctly.

1. geo_to_ht docstring is inaccurate

The docstring states the returned heights are "approximate ellipsoidal heights referenced to WGS84" and that "by calculating the ellipsoid here we directly reference to WGS84." This conflates two separate things: the Earth-radius parameter used in the conversion, and the vertical datum the heights are referenced to.

The vertical datum is inherited from the input. calcgeoh integrates upward from z_surface (the ERA5 surface geopotential), which ECMWF references to the geoid (mean sea level ≈ geoid). The resulting geopotential height, and therefore the geometric height from geo_to_ht, is referenced to the geoid. Using a latitude-dependent Earth radius (get_Re) and gravity (_get_g_ll) generalizes the spherical Re·h/(Re−h) formula to account for local gravity/radius, but these are scale factors in the height conversion; they do not shift the origin of the vertical datum.

Converting geoid-referenced geometric height to true WGS-84 ellipsoidal height requires adding the geoid undulation N (roughly ±100 m globally), which is not applied anywhere in the function.

Suggested docstring correction:

Convert geopotential height to geometric height (height above the geoid / mean sea level) using latitude-dependent gravity and Earth radius.

No code change is needed — the formula is fine (and reduces to the standard spherical geometric-height formula when g_ll == G0). This is docstring-only.

2. Check DEM vertical datum handling in the AOI documentation

We need to check whether both georeferenced DEMs and hgt.rdr files are properly handled in terms of their height datums in the llreader.py class definitions.

Requests for this issue:

• Confirm which vertical datum RAiDER assumes for input DEMs, and whether any geoid correction is applied before DEM intersection.
• Document that assumption explicitly (user docs / AOI section), so users supplying their own DEM know whether it must be geoid- or ellipsoid-referenced, and what happens if there's a mismatch.
• If no correction is applied, note the expected magnitude/behavior of the resulting error so users can judge whether it's relevant for their AOI.
• Update the docstring for geo_to_hgt to reflect the correct existing behavior.