measure_effect_cost's OD_PRE_GAIN is a decimal a board and a desktop do not round to the same float32, so every @drive* row splits

[bdbarnett]

tools/measure_effect_cost.py writes OD_PRE_GAIN = 11.7709228 as a
literal, with the comment "written here as a literal so every leg feeds the
node the SAME number. The class computes it in Python floats, which are
double on CPython and on the unix build and single on a board; that
difference belongs to the class row and would otherwise be measured here as
if it were the node's."

A literal does not achieve that when the decimal is not exactly
representable. A board parses 11.7709228 once, in mp_float_t (single),
and holds 413c55b4. A desktop parses it in double and the node rounds that
to 413c55b3. One ULP apart, and the node is handed a different number on
each leg — which is exactly what the comment says the row exists to avoid.

Measured on the P4 (2026-09-18, audioif e3b95e7):

mpftp exec -d COM4 'import struct, binascii
print(binascii.hexlify(struct.pack(">f", 11.7709228)).decode())'
  ->  413c55b4
.venv/bin/python -c 'import struct, binascii
print(binascii.hexlify(struct.pack(">f", 11.7709228)).decode())'
  ->  413c55b3

The consequence is that all four audioshaper.Waveshaper@drive1/2/4/8 rows
render different bytes on a board than on either desktop, and the Phase 4
board run of 2026-09-17 recorded that split without a cause. It is the row,
not the node:

target	P4	T-Embed S3	CPython	desktop MicroPython
@drive4 (pre_gain 11.7709228)	7dd67c39a186b05d	=	3de13c30d965d6b1	=
@drive4exact (pre_gain 11.75)	e52f8669fcb8ef41	=	=	=
@drive1exact (pre_gain 11.75)	38835bf9b3e99559	=	=	=
@bits12 (pre_gain 1.0)	117776fe4e37894c	=	=	=

8c3528c adds the three exact-pre_gain rows as the control and leaves
OD_PRE_GAIN alone, because changing it would move every @drive* figure
already in
docs/effects-internal/audits/effects-cost-table.md and those rows are
cited by five evidence packs.

What is owed: decide whether the @drive* rows keep the class's own
decimal (and say in the table that their digests are leg-dependent for this
reason) or move to a pre_gain every format holds — and if they move, re-take
the rows and the packs that cite them in one pass. The same trap applies to
any palette row whose settings are not exactly representable; @x1..@x8
and the @od-*/@ex-* biquad rows should be checked the same way.

Found by the Phase 4 board run, 2026-09-18. Cost figures are unaffected.

[bdbarnett]

Closing under decision 4 (Brad, 2026-09-22): accepted and documented, no code change. OD_PRE_GAIN keeps its decimal.

The value and the two widths

OD_PRE_GAIN = 11.7709228, written as a literal in tools/measure_effect_cost.py. The comment on it is right about the intent and wrong about the mechanism: a literal is parsed at the parsing format's width, and mp_float_t is binary32 on an ESP32 and binary64 on every desktop.

	parses to	as float32
board	413c55b4	11.7709236
desktop	double, then the node rounds	413c55b3 = 11.7709227

1 ULP apart, 9.5e-07 absolute, 8.1e-08 relative. Every audioshaper.Waveshaper@drive1/2/4/8 row therefore renders different bytes on a board than on either desktop, exactly as this issue measured.

Why it is left

Moving OD_PRE_GAIN to a value every format holds would move every @drive* figure already in docs/effects-internal/audits/effects-cost-table.md, and those rows are cited by five evidence packs. Re-taking the rows and the packs in one pass is a bigger change than the defect: the split is one ULP of a pre-gain, the cost figures are unaffected, and 8c3528c already added the @drive*exact control rows at pre_gain 11.75, which is exactly representable and reads the same on all four legs.

So the @drive* rows keep the class's own decimal, and their digests are leg-dependent for this reason — which is the sentence this issue said was owed. It belongs in the cost table beside the rows; that file is in the anchor's docs/, which is not this lane's tree, so it is stated here and on #75 rather than edited in.

The general trap, written where it will be met

lib/audioeffects/_component.py's module docstring now carries it, because the trap is not about this one constant: a literal only makes two legs agree when the decimal is exactly representable in float32. 11.7709228 is not; 11.75 is. Anyone reaching for "write it as a literal so every leg feeds the node the same number" now meets the counter-example in the same paragraph.

Still worth someone's pass, and not done here

This issue's last line asks for the same check over @x1..@x8 and the @od-*/@ex-* biquad rows. Not done: tools/measure_effect_cost.py is held by the T-Embed board agent for #51 and this lane was told to leave it alone. It is a mechanical check — take each row's settings, round-trip through float32, and flag any that change — and it wants the board leg to confirm, so it belongs with whoever holds the cost runner.