Fix PixelIsPoint overview coord offset (#1642)

PR #1641 (issue #1640) inherits level-0 georef on overview reads but
keeps the level-0 origin_x / origin_y unchanged. That is correct for
PixelIsArea -- origin is the upper-left corner of pixel (0, 0), which
is also the upper-left corner of the overview's pixel (0, 0). It is
wrong for PixelIsPoint (GeoKey 1025 = 2): the origin is the center of
pixel (0, 0), and an overview pixel covering the first scale_x columns
of level 0 has its center at the centroid of those level-0 pixels
(origin + (scale - 1) * 0.5 * pixel_size_lvl0).

Before this fix, open_geotiff on a 1024x1024 PixelIsPoint COG with
10 m pixels and origin (0, 0) returned x[:3] = [0, 20, 40] for
overview_level=1 instead of [5, 25, 45]. Downstream sel / interp /
reproject silently snaps to the wrong pixel for any DEM-style
PixelIsPoint COG (USGS, OpenTopography, Copernicus DEM).

Fix in extract_geo_info_with_overview_inheritance: choose the
effective raster_type first (overview's own when it explicitly
declared non-default, otherwise inherit from level 0), then apply
origin_shift = (scale - 1) * 0.5 * pixel_size_lvl0 along each axis
when that effective raster_type is PixelIsPoint. The PixelIsArea path
is byte-equivalent to before.

Add 13 regression tests in test_overview_pixel_is_point_1642.py:
centroid identity across all four backends, transform-tuple values
across all four backends, uniform grid step, unit-level helper tests
for both raster_types via stubbed extract_geo_info, an own-geokeys-
not-clobbered case on PixelIsPoint, and a PixelIsArea regression
check so the #1640 contract still holds. All 1397 existing non-network
geotiff tests still pass.

Author: brendancol