test: cover all four order and sizing variants

[oberbichler]

Why

The C++ suite ran almost entirely on DDScalar<2, double, 3>. Templates that are never instantiated are never compiled, so neither the tests, nor the warnings, nor the sanitizer job from #75 could see the first-order or dynamic code paths at all.

That is not hypothetical. It is why the deduction failure in #78 survived — the only caller of that overload passed the size explicitly — and why turning on -Wall -Wextra in #75 produced zero warnings over a header that had five.

What

A second layer in its own translation unit: 14 TEST_CASE_TEMPLATEs over {order 1, 2} × {static, dynamic} — 56 test cases, 853 assertions.

	covers
values	f/g/h accessors, both index forms, setters — the linear h(i) is not exposed to Python, so this is its only coverage
factories	empty, zero, constant, variable, variables
neg add sub mul div	with a dual and with a scalar, both operand orders
in place	+= -= *= /= against the same expectations as the binary forms
unary/binary/ternary functions	sqrt, exp / atan2 / hypot(a,b,c) — one per arity, since all the math functions funnel through those three
eval	order-dependent expectation
padding	pad_left/pad_right, dynamic only

The expected values were derived symbolically from quadratic Taylor polynomials, so they share no formulas with the header. One set of numbers serves both orders: the first-order part of every operation depends only on the first-order parts of its inputs, so truncating a second-order expectation to [f, g...] gives the first-order one — the same trick the Python tests already use in VariableSet.from_data.

These tests passed on the first run

Which on its own proves nothing, so they were validated by mutation. Two deliberate faults in the header, counting failing test cases in the old suite against the new one:

mutation	old suite	new suite
unary() skips the gradient loop at order 1 (TOrder < 1 → TOrder < 2)	0 failed	4 failed
data_length() one short for the dynamic variant	1 failed	22 failed

The first is completely invisible to the old suite. It breaks every math function for every first-order type — sqrt, exp, all 20 of them — and would ship green.

Verification

• 101 test cases, 1302 assertions in Debug, Release, and under clang with ASan+UBSan, all with -Werror
• Python 172 passed — and identical with this file stashed, confirming no production-side change

One caveat worth recording: on first run the Python suite showed 4 failures, which turned out to be a stale extension build from #78's branch predating #76's aliasing fix — not a regression. After uv sync --reinstall-package hyperjet, 172 passed.

Notes

No production changes. Test-only.

Kept separate from test.cpp rather than converting it. That file holds hand-verified numbers for one variant in full detail, which is worth keeping as-is, and a separate TU compiles in parallel (1.8 s next to 3.2 s). The cost is some overlap between the two layers for the DDScalar<2, double, 3> case; consolidating is a later call.

Not covered here, still open from the review:

• SScalar has no cross-variant axis to parametrize over, but its Python coverage is thin (init, mul, and the self-op tests from fix: handle aliased operands in the in-place operators #76) — no division, trigonometry, or comparisons.
• No coverage measurement, which is what would turn "these paths are covered" from an argument into a number.