A derivative field in the step schema, with its usage measured at zero

[punnerud]

A derivative field in the step schema, like calc -- with its usage measured at zero

The field, the parser, the loop wiring, the UI chip, the graphdb fact and the
bench capture are all in place and tested: 'd/dx at x=' is
settled by mpeqs.calculus, whose two independent derivative paths must agree,
and what cannot be settled -- x**x, sin(x), a missing point -- is silence
rather than a guess.

What the measurement says, and it is not the story the field was built for:
re-run on the calculus domain the model filled the field ZERO times in eight
questions -- and scored 8/8 anyway, up from 5/8. The visible mechanism is the
CALC field: the model applies the chain rule itself and hands the resulting
arithmetic over, "3*(4*(-2)^2 + 6)^2 * 8*(-2)" evaluated exactly. The earlier
misses were arithmetic slips in exactly that step, so the existing machinery
carries derivative questions once the model writes the expression down.

8/8 against 5/8 at n=8 is inside the measured noise floor and is NOT claimed as
the field's effect; nothing that never fired can have caused anything. The
field stays because it is passive -- an empty string costs nothing, silence is
the failure mode -- and a model that does reach for it gets an answer that
cannot be a matching mistake. The same shape as the convert field's early
history, where required-but-unused preceded used-and-decisive by one model
generation.

Found and fixed on the way: the UI edit split the calc handler and orphaned its
chip code inside the new branch, killing every sums chip -- caught by the
existing render tests, both handlers now share one exactChip helper.

9 tests here, 461 in all.