Reject a matrix file whose modulus does not fit in Scalar

[d-torrance]

SparseMatrix::read reads the modulus with readOne<uint32> and returns it as
SparseMatrix::Scalar, which is uint16. A file claiming 65637 was read as
101.

Nothing downstream could tell. The primality check PR #74 added sees only the
truncated value, and 101 is prime, so the reduction ran over a field the file
never named — and the result was written back out claiming 101.

It is silent corruption, not a misread

Two hand-built .brmat files, identical but for the modulus field, 65637 and
101:

$ mgb matrix big.brmat
$ mgb matrix small.brmat
$ cmp big.rbrmat small.rbrmat && echo identical
identical

Reading the header of big.rbrmat back shows modulus 101. The 65637 is gone
with no diagnostic anywhere.

The fix

Check the value where the uint32 is still intact, through the same error path
the rest of read already uses, so mgb matrix reports it and exits instead of
producing a wrong answer:

$ mgb matrix big.brmat
ERROR: The matrix file has modulus 65637, which does not fit in the 16 bits
that this file format stores coefficients in.
$ mgb matrix small.brmat        # still fine

This is narrow in practice, and worth saying so: write takes a Scalar, so
nothing mgb produces can trigger it, and entries are uint16, so a modulus
above 2^16 is not representable in this format regardless. The point is that a
file asserting something we cannot honour is now refused rather than quietly
reinterpreted.

Two commits

1. 51463eb — the check, and a regression test. The test patches the
   modulus field of a written file directly, since write takes a Scalar and
   cannot produce an out-of-range one. It fails without the check.
2. eedaf0f — return static_cast<Scalar>(modulus);. No functional change:
   the narrowing already happened implicitly, and it is safe now that the
   previous commit rejects anything too large. It silences a -Wconversion
   warning, which this project does not enable today, though
   doc/description.txt asks for a build target that would.

Each builds and passes standalone.

Verification

• The new test fails without the check and passes with it.
• cmake Release and Debug both pass 248/248, with no build warnings.
• The CLI reproduction above: errors on the 65637 file, still succeeds on the
  101 one.
• autotools make distcheck passes.

Not included

The review that found this also noted that PR #74's primality check lives in
src/cli/MatrixAction.cpp, where it cannot be unit tested at all —
mathicgb-unit-tests links no src/cli object. Moving that validation into
SparseMatrix::read and QuadMatrix::read would fix that, but it moves a
policy decision from the CLI into the library and deserves its own PR.

🤖 Generated with Claude Code