fix(inversion): zero-signal adapt image gives NaN on the JAX path

[Jammy2211]

Summary

Closes #548.

adaptive_pixel_signals_from normalised the pixel signals by their maximum with
xp.where(max_sig > 0, pixel_signals / max_sig, pixel_signals). The where guards the
selection but the division is still evaluated for every element, so a zero-signal adapt
image — one whose emission lands nowhere near the pixels being adapted — makes max_sig
exactly 0 and puts a 0/0 NaN in the unselected branch.

Both divisions now use a safe denominator, matching the idiom already used for
pixel_counts two lines above. The step-8 exponentiation carries the same trap one step
on — 0.0 ** signal_scale is finite forwards but its derivative is infinite for
signal_scale < 1 — so it now exponentiates a safe base and selects zero for non-positive
signals afterwards.

The diagnosis in the issue needed sharpening, and it changes what this PR claims. The
two backends already agreed in the forward pass: jnp.where selects correctly, so a JAX
forward result was finite. What actually diverged is (a) NumPy's discarded
RuntimeWarning: invalid value encountered in divide and (b) the gradient — under
jax.grad the NaN escapes the discarded branch. Six of the eight new tests pass on the
unfixed code; only the clean-warning and finite-gradient legs go red. So this fixes a real
NaN on the gradient path, but it does not by itself explain the reported
JAX(no jit) fit.log_likelihood: nan in the originating workspace run — something there
was differentiating. That residual is called out rather than papered over.

API Changes

None — internal changes only.

Two degenerate corners of adaptive_pixel_signals_from change deliberately, both away
from a wrong answer, and neither is a signature or symbol change:

• signal_scale == 0 with a zero signal returned 1.0 (the 0 ** 0 convention) and now
  returns 0.0.
• A negative pixel signal returned NaN for a fractional signal_scale, or a spurious
  positive weight for an even integer one, and now returns 0.0 — the signals are
  documented as varying between 0 and 1, so a non-positive signal contributes nothing.
  (The sibling image_mesh/abstract_weighted.py already takes np.abs(adapt_data), so
  treating negative adapt signal as carrying no positive weight is consistent with the
  surrounding code.)

Behaviour is otherwise identical wherever it was previously well-defined.

Test Plan

• pytest test_autoarray — 1438 passed, 74 skipped, 0 failed (with the
  [optional] extras installed; see the note below).
• pytest test_autoarray/inversion/pixelization/mappers/ — 27 passed.
• Eight new tests in test_mapper_util.py: NumPy value and finiteness, a
  RuntimeWarning-as-error assertion, finiteness parametrised over
  signal_scale in {0.5, 1.0, 2.0}, NumPy/JAX parity both with and without signal,
  and a finite jax.grad. JAX legs carry the repo's existing requires_jax skipif
  convention (as in test_delaunay.py).
• Verified red before the fix: the clean-warning and finite-gradient legs fail on
  the unfixed code and pass after.

Pattern sweep — issue #548 ask (3)

Done as an AST pass over the whole package, not grep, so multi-line calls could not
slip past: every where(cond, x, y) with a division anywhere inside either branch.

Site	Verdict
inversion/mappers/mapper_util.py:84	the bug — fixed here
inversion/mesh/interpolator/delaunay.py:390	safe — divides by the literal 3.0
inversion/mesh/interpolator/sibson.py:826	safe — divides by the literal 3.0
inversion/mesh/image_mesh/abstract_weighted.py:72	safe — explicit if max_value <= 0.0 early return
dataset/preprocess.py ×3, dataset/imaging/dataset.py:507	NumPy-only preprocessing; divide by a user-supplied scalar, not on the JAX path
fit/fit_util.py:251, 452, 474	same bug class, live — filed separately

fit/fit_util.py:251 (chi_squared_map_with_mask_from) is on the JAX likelihood-gradient
path and was confirmed by direct reproduction: with a masked-out pixel carrying zero noise
the forward value is finite (2.0) while jax.grad returns [2., 1., nan]. Different
module, own test surface, so it is filed as its own PyAutoMind prompt rather than widening
this PR.

Note on running the suite locally

Without the [optional] extras, eight inversion/inversion tests fail with
ModuleNotFoundError: No module named 'numba' (w-tilde pixelized reconstructions are
disabled without it). That is an environment artifact, not a defect — installing numba
takes the suite to a clean 1438 passed. Recorded here because it briefly looked like
pre-existing breakage on main and is not.

Generated by the PyAutoLabs agent workflow.

---

Generated by Claude Code