spot-selection.game.json records 23.872 for a computation it records as 23.873 in 404 other rows

[wormeyman]

What

test/fixtures/spot-selection.game.json records two different 3-decimal values
for the same computation. In case hard1, spots at sorted index 0 and 2 carry a
peak of 23.872. Both have quantity = 10000 and coneScale = 1, which is
arithmetically identical to the dens1 .. dens6 spots - and those are recorded
as 23.873.

Across all 55 cases there are only 9 distinct peak values, and 23.873
appears 404 times against these two 23.872 rows.

The port computes 3 * 10000 / (pi * 400) = 23.8732414637843, which rounds to
23.873. So the port agrees with 404 rows and disagrees with 2, and the 2 are
the ones that disagree with the other 404.

Why it matters

The peak column was captured with deliberate 3-decimal rounding, so a tolerance
is correct there and must stay - Math.fround(v) === v is 0/413 on that column
by construction. But the bound is 0.005, ten times looser than a 3-decimal
capture justifies (half of the last recorded digit is 0.0005).

That extra slack exists to absorb these two rows, and it costs real
discrimination. Measured:

cube root	coneScale	peak	rounds to	|d| to fixture	at 5e-4
fastCbrt (shipped)	0.7936897277832031	18.948719893	18.949	2.801e-4	passes
Math.cbrt	0.7937005259840998	18.948204307	18.948	7.957e-4	fails

So swapping the fastapprox cube root for the exact one moves
peak-within-0.0005 from 411/413 to 410/413 - and passes the current 0.005
bound unchanged. Exactly one spot in the whole fixture discriminates
fastCbrt, and today's bound cannot read it.

What to do

Settle what hard1's 23.872 actually is before touching the bound. Either it
is a capture artifact (most likely - the arithmetic says 23.873), or hard1's
hardRegionTargetQuantity path produces a genuinely different quantity for
those two spots and the port is wrong about it.

Once settled, the bound can drop to 0.0005 and the fastCbrt guard becomes real.
Do not drop the bound first and edit the fixture to match - a mismatch is a
finding.

Also

spots[][0] and spots[][1] are already graded exactly and score 413/413 with
worst residual 0, across 55 cases with no spot-count disagreement. Those columns
are fine. This is only about the peak column.

Found while scoring the phase-1 primitives for #220. See #256 for the wider
programme.