refactor: drop the runtime size from statically sized scalars

[oberbichler]

Problem

m_size only means anything when TSize is Dynamic. For every other variant it was eight bytes that nothing reads — and the constructor taking Data never set them, which is what clang-tidy reported in #80:

hyperjet.h:322: 1 uninitialized field at the end of the constructor call
                [clang-analyzer-optin.cplusplus.UninitializedObject]
  322 |   DDScalar(const Data &data) : m_data(data) {
   56 |   index m_size;   <- uninitialized

Nothing read the field, so nothing was visibly wrong. But every copy of such an object copied an indeterminate value, which is UB to read and would trip MSan.

Change

The field gets an empty stand-in type for the static variants, marked [[no_unique_address]] ([[msvc::no_unique_address]] on MSVC, which still needs the vendor spelling). A static scalar is now exactly its data:

	before	after
DDScalar<1, double, 3>	40	32
DDScalar<2, double, 3>	88	80
DDScalar<2, double, 8>	368	360
DDScalar<2, double, 16>	1232	1224
DDScalar<2, double, Dynamic>	32	32

The initializer-list constructor is the one place that runs for both variants and set the field from its member initializer list. It now computes the size into a local and only stores it when there is somewhere to store it.

Why this matters beyond the lint

This settles the layout question a NumPy dtype asks of its element type. A static scalar is now payload-sized and trivially copyable; the dynamic one is neither — which is the concrete reason only the static variants could ever back a dtype. Eight bytes per element of dead weight would otherwise have been an uninitialized byte range inside every array element, plus 10 % wasted bandwidth on the hot path for size 3.

Not a performance change — measured, not assumed

Five alternating runs of a * b + a.sin() over 20k elements, -O3 -DNDEBUG:

	main	this branch
size 3	10.81 · 10.85 · 10.86 · 10.92 · 13.27¹	10.74 · 10.81 · 10.91 · 10.93 · 11.00
size 8	52.04 · 52.11 · 52.22 · 52.47 · 52.89	51.60 · 51.84 · 51.87 · 51.91 · 52.41

¹ first run, cold start

Size 3 unchanged; size 8 consistently a little faster in all five runs — the smaller object pays off marginally. Worth recording: my first measurement showed 17.96 → 20.12 ns and looked like a 12 % regression. It was cold-start noise, and repeating it is what showed that.

Verification

• C++ 102 test cases, 1310 assertions — Release with -Werror, and under clang with ASan+UBSan
• Python 172 passed; exported API dump identical against a build of the previous state
• clang-tidy 51 → 50 findings, the uninitialized field gone, 0 errors

TEST_CASE("Static scalars are exactly their data") pins it: sizeof(T) == sizeof(T::Data) for sizes 0, 3 and 8 across both orders, trivial copyability and standard layout for the static variants, and CHECK_FALSE(is_trivially_copyable_v<...>) for the dynamic one. RED was 4 of its 8 checks failing.

Notes

Based on main. Independent of #81 (binding codegen, still open) — that one touches python/, this one include/.

Next in the sequence we discussed: the NumPy dtype itself, once #81 lands.