Correct the addend flag: it picks immediate or register, not present or absent

[AndreSlavescu]

A flag landed under the wrong name, and the wrong name came from a reading that had already
survived a prediction — which is the interesting part.

It was ADDEND_ENABLE, described as including the addend or not, because clearing it turned
a*m+d into a*m on four inputs.

Clearing it actually switches the addend slot from an immediate to a register. The synthesised
instruction that verified "a*m" had an ordinary encoded constant left in the slot, 0xb0, and with
the immediate bit clear that byte names register 88 — above the sixteen the field reaches, so it
reads zero. The addend was never absent. It was zero, by accident, and the prediction passed
because zero and absent are indistinguishable in a sum.

The register form

Same shape as the register field elsewhere: r << 1, low bit ignored. Verified by rewriting
instructions to rd = rd * m + rs for every ordered pair of three live registers at two
multipliers, predicting all four threads each — 18 rewrites, 72 exact values.

That gives the register-plus-register add, as rd * 1 + rs, which no immediate form can
express. encode_fma now takes either an immediate addend or an addend_register and refuses
both at once. A zero addend is stated for what it is — a register index chosen because it cannot
be reached — with a test asserting that property, so a future part with more registers cannot
silently turn it into whatever that register holds.

One more prediction miss, where the encoding was right and my model was wrong

The register-addend rewrites first matched on thread 0 and failed on the other three: thread gid
reads x[gid], x[gid+1], x[gid+2], and my prediction used thread 0's inputs throughout. 18 of
18 once the shift was applied. When a hypothesis matches exactly on one thread and misses on the
rest, the harness is the suspect, not the field map.

29 ISA tests. Lint clean.

🤖 Generated with Claude Code