Apply quadrature weights out of place so autograd survives GaussLegendre

[gomezzz]

BaseIntegrator.evaluate_integrand ended with result *= weights — an in-place
multiply on the tensor the user's integrand had just returned. torchquad does not
own that tensor.

• Breaks autograd on the headline feature. Any integrand whose last operation
  reads its own output in the backward pass — exp, sqrt, tanh, sigmoid,
  div, pow — raises RuntimeError: one of the variables needed for gradient computation has been modified by an inplace operation ... is at version 1; expected version 0. Same failure for gradients with respect to the integration
  domain, on CPU and GPU. Only the Gaussian family passes weights here
  (GridIntegrator._weights returns None), so Newton–Cotes and Monte Carlo were
  unaffected, as was JAX. Present since 0.4.0 (Gaussian quadrature #141).
• Why nothing caught it: gradient_test.py listed six integrators but only
  five point counts, so zip silently dropped GaussLegendre — the only
  integrator that reaches this code — from every gradient test. And every existing
  test integrand (2|x|, polynomials) has a backward pass that does not read its
  own output, so even with GaussLegendre restored they would all still pass.

Found while validating the 0.6.0 release; not a 0.6.0 regression. It fails
loudly rather than returning wrong numbers, so no published result is at risk.

Related to #258.

Numerical behaviour

The multiplication is identical; only its destination changed. No tolerance was
loosened, and the full suite passes unchanged on all four backends.

One deliberate behaviour change: an in-place multiply takes its left operand's
dtype, so an integrand returning float32 under float64 precision silently
discarded the weights' precision. Out-of-place promotes instead, which is what
"no silent precision downgrades" requires. tests/base_integrator_test.py::test_weight_dtype_*
pins this.

GaussLegendre gets 499 rather than 149 points in the 1-D gradient tests: the
V-shaped integrands there have a kink, and Gauss–Legendre is only O(N^-2) on
|x| while being spectrally accurate on the smooth exponential at any of these
N. Raising N rather than loosening a tolerance.

Test plan

• New tests/base_integrator_test.py — 10 tests asserting the integrand's
  returned tensor is unchanged after evaluate_integrand, for scalar and
  multi-value integrands, on numpy/torch/jax/tensorflow, plus the dtype guard.
  Verified these fail without the fix (numpy and torch; jax and tensorflow
  pass trivially since their tensors are immutable).
• gradient_test.py — GaussLegendre restored to the matrix with a
  length assertion, and a new exponential integrand whose exact gradient is
  1.0. Verified this fails without the fix with the precise
  ExpBackward0 error, and passes with it, on torch/jax/tensorflow.
• Full suite: 203 passed across all four backends (was 193; +10 new).
• Gates: ruff check clean, ruff format --check clean (64 files),
  pydoclint torchquad/ no violations, vulture --min-confidence 100 clean.
• Fix confirmed against an analytic reference: d/da ∫₀² e^{-a x²} dx at
  a = 0.7 gives -0.6561422331326556 versus a fine-grid reference of
  -0.6561422331326168.

What changed after review

• The silent upcast now warns. Applying the weights out of place stopped the
  silent downcast but replaced it with a silent promotion, which the fail-hard
  rule objects to equally. A dtype mismatch now warns, matching the
  backend-mismatch warning ten lines above it. The check compares mantissa width,
  so a complex128 integrand against float64 weights stays quiet — it loses no
  precision — while float32 or complex64 against float64 does not. Verified
  against the full suite: the only warnings emitted are the four pre-existing
  Boole/Simpson N-adjustment ones.
• The guarantee moved into the docstring. evaluate_integrand is public API
  and the tutorial shows users calling it directly; a contract that lives only in
  an inline comment is one refactor from being reintroduced as *=.
• The parallel lists in gradient_test.py became one list of tuples, so they
  cannot drift out of sync again rather than being caught by an assert after the
  fact.
• The exponential case skips MonteCarlo and VEGAS, which never reach the
  weights branch and were already covered by the four preceding integrands, and
  its bound tightened from 5e-2 to 1e-4. The old bound was set by Monte Carlo
  and would have passed a several-percent error in weight application on the
  deterministic rules; 1e-4 is limited by Trapezoid at 1.7e-5, while Boole and
  GaussLegendre reach 1e-15.
• Two new tests: the mismatch warning fires, and a matching (or complex)
  integrand stays quiet.
• Full suite now 205 passed, gates all still clean.

Not addressed here

Gaussian._weights(self, N, dim, backend, requires_grad=False) never receives
requires_grad from any of its four callers, so weights.requires_grad = requires_grad is a permanent no-op. Confirmed, but unrelated to this fix and
better as its own change — _roots does use the parameter, so it is not a
blanket removal.

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
torchquad
__init__.py	26	2	92%	69–70
torchquad/integration
base_integrator.py	54	7	87%	41, 95–98, 102, 152, 156, 161
boole.py	30	3	90%	54, 73–76
gaussian.py	56	2	96%	121, 143
grid_integrator.py	97	3	97%	50, 164, 268
integration_grid.py	49	4	92%	64–65, 132, 135
monte_carlo.py	93	3	97%	79, 101, 230
qmc.py	20	1	95%	67
rng.py	60	7	88%	71–74, 93–94, 102
simpson.py	29	3	90%	52, 71–74
utils.py	131	11	92%	35–36, 102, 173, 177, 184, 196, 198, 204, 299, 306
vegas.py	167	4	98%	106–107, 212, 359
vegas_map.py	103	8	92%	247–257
vegas_result.py	25	1	96%	22
torchquad/utils
deployment_test.py	192	63	67%	53–55, 65–66, 69–70, 78–79, 91–93, 164, 175–176, 180–181, 183–184, 196–199, 211–213, 221, 232–234, 237, 247, 250, 253, 256–259, 267–275, 280–288, 297–306, 316–323
enable_cuda.py	15	6	60%	17–22
set_log_level.py	18	4	78%	56–57, 72–73
set_precision.py	34	9	74%	35–38, 50–51, 70–72
TOTAL	1295	141	89%

Tests	Skipped	Failures	Errors	Time
205	0 💤	0 ❌	0 🔥	2m 25s ⏱️

[sylvesterkaczmarek]

The precision table compares storage width rather than significand precision: bfloat16 and float16 are both mapped to 16 even though bfloat16 is less precise. A bfloat16 integrand with float16 weights therefore skips this warning. Please rank by actual mantissa precision and add that mixed-dtype case to the tests.