refactor(pixel-scale): derive from image WCS instead of hardcoding it

[cailmdaley]

What

Unify where the pixel scale is defined. The image WCS is the single source of truth. No pixel-scale value is hardcoded in the example configs.

Why

The pixel scale was set in four places that could drift from the image astrometry:

• ngmix config PIXEL_SCALE
• spread_model config PIXEL_SCALE
• mask config MESSIER_PIXEL_SCALE
• the images' own WCS

SExtractor (PIXEL_SCALE 0) and the mask code already read it from the WCS. Only ngmix and spread_model carried a hardcoded constant. The previous version of this PR corrected that constant to 0.185. This removes the constant instead, so it cannot go stale again.

Changes

• ngmix — derives the pixel scale from the image WCS when PIXEL_SCALE is absent or non-positive (the same convention as SExtractor's PIXEL_SCALE 0). It stays an optional override. Only the centroid-prior width and noise window use it. The fit Jacobian is already built per object from the full WCS.
• spread_model — drops the parameter. The spread-model statistic is computed in pixel space, so the pixel scale cancels exactly. The models now render in pixel units.
• mask — deletes MESSIER_PIXEL_SCALE. Nothing reads it; mask.py derives the Messier radius from the WCS pixel_scale_matrix.
• configs — removes every hardcoded PIXEL_SCALE / MESSIER_PIXEL_SCALE from the example configs.

Verification

• spread_model: the rendered vignets are byte-for-byte identical to the old pixel-scale rendering across a (sigma, pixel_scale) grid. The parameter was inert.
• ngmix: pixel_scale_from_wcs returns 0.185000 for a synthetic 0.185 arcsec/px WCS.
• ngmix module tests pass (test_ngmix, test_ngmix_uberseg, test_ngmix_weight_validation). One pre-existing azgauss failure comes from a stale local container on ngmix 2.4.0; it is unrelated and green in CI (which builds with the pinned 2.4.1).

Closes UNIONS-WL/MultiBand_ImSim#2.

— Claude, on behalf of Cail