fix: delete only cache tiles that can touch the previous footprint (MAPCO-12035)

[CL-SHLOMIKONCHA]

Question	Answer
Bug fix	✔
New feature	✖
Breaking change	✖
Deprecations	✖
Documentation	✖
Tests added	✔
Chore	✖

Related issues: MAPCO-12035

Further information:

Problem. The update cache deletion job walks the whole update area from zoom 0 to the configured max zoom (21). An update that adds a new area next to an existing layer therefore produces millions of deletion tiles, almost all above zoom 16, for ground that was never served and so never cached in redis.

Change.

• updateJobHandler: at init, before the polygon parts are merged into the catalog, the current catalog footprint is stored on the job as additionalParams.previousFootprint. This is best effort; if the catalog lookup fails a warning is logged and the deletion falls back to the full walk.
• cacheDeletionJobCreator: with a previous footprint on the job, the walk runs per zoom and clips the update area's tile ranges to the tiles touching the previous footprint's bbox. The box uses closed bounds (ceil - 1 on the min side, floor on the max side), so an edge lying exactly on a grid line claims the tile on either side, the same rule footprintToTileRanges applies to footprints. This is plain range arithmetic in grid units, exact at any latitude, with no buffer. Because the bbox of an irregular footprint also holds ground the layer never covered, each clipped range is then checked against the footprint itself with booleanIntersects and dropped when its ground does not touch it. The first zoom with no surviving range ends the walk, because a child tile cannot be shared by both areas when its parent is not.
• jobParameters.schema: previousFootprint (Polygon or MultiPolygon, optional) on the update and swap finalize params.

What gets deleted. The result is exactly the update tiles whose squares touch the previous footprint, at every zoom, which is every tile MapProxy could have rendered for the old layer inside the update. Whether a given tile is actually in redis is not known here; the cleaner unlinks the key either way. Tiles MapProxy may have served beyond the catalog footprint are left to the cache TTL, see below.

Example. A layer near 34.3°E 31.35°N updated with a disjoint polygon near 35.5°E 33.9°N, 2.7° away, now produces four ranges, one tile per zoom from 0 to 3, instead of about 1.9 million tiles across zooms 0 to 21. From zoom 4 on no tile covers both footprints and the walk stops.

Trade-offs, kept on purpose.

• Zooms above the layer's resolution inside the overlap are still enumerated up to max zoom.
• Tiles outside the previous footprint that MapProxy upscaled into redis are left to the cache TTL.

Tests. Unit tests cover the fallback walk, a disjoint update (walk stops at the last zoom with a shared tile, exhaustive oracle for tiles touching both), an overlapping update (reaches max zoom but stays inside the tiles touching the previous bbox), the same at latitude 32, an update in the notch of an L-shaped layer (stops early, all tiles touching both arms covered), and the footprint recording and its fallback in the update handler.