Fix CI and CD: twine metadata, mypy/numpy/python version clash

[AlecThomson]

Fixes the red CI and CD on main, which was also blocking #8, #13 and #14.

main's last CI run was 2026-05-22, so it looked green but was stale. Fresh
workflow_dispatch runs on main today confirmed both workflows fail
(CI,
CD).

CD — Distribution build

twine check --strict failed with:

InvalidDistribution: Invalid distribution metadata: '2.5' is not a valid metadata version

hatchling emits Metadata-Version: 2.5, which only Twine 7 understands.
build-and-inspect-python-package picked up Twine 7 in v3.0.0 — but v3 also
stopped force-tagging minor releases, so the floating @v2 tag we were on could
never receive the fix. This one was not going to heal on its own.

Pinned to @v3.0.1.

CI — Format

mypy failed while parsing numpy's own stubs:

numpy/__init__.pyi:737: error: Type statement is only supported in Python 3.12 and greater  [syntax]

The Format job runs on 3.x (3.14), where numpy resolves to 2.5.x, whose stubs
use PEP 695 type statements. mypy was targeting 3.10 and refused to parse them.

This is the numpy / mypy / python version clash from #14. The root of it is that
requires-python was raised to >=3.11 in e9fba2e ("Add the codes") when the
real code landed, but three leftovers from the scientific-python/cookie template
were never updated with it:

• Programming Language :: Python :: 3.10 classifier
• [tool.mypy] python_version = "3.10"
• CI matrix "3.10" — and 3.11 was never in the matrix at all

3.10 is not installable anyway: numpy, astropy, scipy, reproject and capn-crunch
all require >=3.11.

So rather than raising the mypy target to 3.12, this keeps the type check honest
at the project's real minimum:

• python_version = "3.11"
• mypy hook pinned via language_version: python3.11, which resolves numpy to
  the 2.4.x line whose stubs parse at that target
• the Format job installs 3.11 alongside 3.x so the hook can find it (3.x
  stays last and remains the interpreter pre-commit itself runs on)
• matrix is now ["3.11", "3.12", "3.13", "3.14"], so the minimum supported
  version is actually exercised for the first time
• 3.10 classifier dropped

A real bug this uncovered

Type-checking against a supported Python surfaced a genuine bug that the 3.10
target had been masking:

masking.py:910: error: Argument "mask" to "beam_shape_erode" has incompatible type
ndarray[..., dtype[numpy.bool]]; expected ndarray[..., dtype[floating]]

reverse_negative_flood_fill returns a bool array. It was passed to
beam_shape_erode (which expects floats) and then handed to fits.writeto,
where astropy rejects it. That is exactly the failure Beth reported via #14.

Fixed by casting the flood-fill mask to float32 where it is created, so both
the erosion step and the FITS write get a float array, and dropping the
now-redundant type: ignore[assignment].

Because beam_shape_erode derives its return dtype from its input, fixing the
dtype at the source also removes the bool return it could previously produce —
so its return-dtype docstring, which was wrong in both branches it described,
is corrected here too.

This overlaps #14, which applied .astype(np.float32) at the writeto call.
That cast is kept on #14: it is no longer load-bearing for the bool bug, but the
multi-scale path of beam_shape_erode still returns float64, so it is what keeps
the mask on disk at float32.

Test coverage

codecov flagged 0% patch coverage, and it was right twice over — both gaps sat
directly on the path of this bug:

• every existing mask test ran with flood_fill=False, so nothing exercised the
  branch that built the bool array
• nothing called create_snr_mask_from_fits with beam_shape_erode=True, so the
  one place the bool mask was passed into a float-typed parameter was never run

Two tests added for those paths. The first was verified to fail without the fix,
raising the same KeyError from astropy's image HDU on write that Beth hit.

Verification

• pre-commit run --hook-stage manual --all-files — all hooks pass locally
• pytest — 22 passed
• mypy reproduced against a Python 3.14 / numpy 2.5.3 environment to confirm both
  the CI failure and the fix, not just the local 3.11 / numpy 2.4.6 one
• all 8 checks green on the current head, codecov included

Once this lands, #13 and #8 need only a branch update to go green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GTPJweMZavwh86CQ7qH7rb

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!