moisture and aux keep a 1-4 ulp residual that the 1/256 snap does not explain

[wormeyman]

The premise of this issue is refuted, and the title is now what remains.
Original title: "Re-capture the temperature / moisture / aux fixtures on the
1/256 grid".

No re-capture is needed

Measured 2026-08-18. Factorio's MapPosition is fixed point, int32 / 256, so
a capture coordinate that is not a multiple of 1/256 is truncated toward zero on
the way in and the game evaluates somewhere the fixture never recorded. The fix
is to snap the recorded coordinate the same way at read time, which needs no
Factorio install and no new capture:

fixture	as recorded	snapped
oracle-temperature	17/26 exact, worst 5.817e-5	26/26 exact, worst 0
oracle-moisture	15/26, worst 3.070e-5	18/26, worst 5.960e-8
oracle-aux	10/26, worst 1.262e-5	14/26, worst 5.960e-8

The same correction applies to 17 fixtures, not three. All 17 improve, none
gets worse, and two reach worst residual 0. Full table, controls and the
trunc-vs-floor evidence are in test/captureGrid.ts.

What is actually left, and it is smaller and stranger

moisture and aux do not reach 100% after the snap:

fixture	exact	misses	ulp distances	of which ON-grid
oracle-moisture	18/26	8	1, 2, 4	3
oracle-aux	14/26	12	1, 4	3

Two things make this worth its own investigation rather than a bound:

• It is not the snap. Three of each spec's misses sit at positions that were
  already on the 1/256 grid, where snapPosition is provably the identity.
• It is not Narrow incoming coordinates to f32 in quickMultioctave, variablePersistence and basisNoise, once a derived-coordinate caller can prove it #191 either. Narrow incoming coordinates to f32 in quickMultioctave, variablePersistence and basisNoise, once a derived-coordinate caller can prove it #191's remaining scope is narrowing the incoming
  coordinates in basisNoise and variablePersistenceMultioctaveNoise. Both
  narrowings were applied and measured against these two fixtures: the counts
  moved not at all - 18/26 and 14/26 before and after. Refuted, so do not
  spend the idea again.

temperature reaching exactly 26/26 through the same tree is the sharpest clue
available: whatever this is, it does not affect that expression.

Related, and probably the same question at a different scale:

• elevationLakes far field is 13/17 at worst 3.815e-6 after the snap.
• elevationNauvis keeps a residual that reaches on-grid rows too - on-grid
  worst 3.072e-4 against off-grid 3.856e-4, the same order - so unlike
  temperature the snap is not the whole story for that tree either.
• oracle-trees-controls clears only partly: 1.139e-5 at
  (0.5000000000000735, 1200.25), where the snap moves x by 7.35e-14 and is a
  no-op, against a nearest on-grid point at 9.717e-6.

Do not

Do not raise any bound to accommodate this, and do not re-capture on the strength
of it - the snap already grades these at the point the game sampled. A 1-to-4 ulp
residual that survives on-grid is a finding about the expression trees, and it is
the kind of thing #256's exact-match scoring exists to keep visible.