build: put FPSemantics=Precise on the VoxelForge module — the experiment never ran

FPSemantics is a per-module ModuleRules property. It had been set on the VoxelM
GAME module, while every line of density code lives in VoxelForge, which kept
compiling /fp:fast. So the run that supposedly "reproduced the residue under
precise semantics" ran under fast semantics and proves nothing.

Retracting the previous commit's conclusion: /fp:fast is NOT eliminated as the
cause, and the notes claiming AUDIT C9 and OPSTACK-PLAN 2.6 are falsified are
withdrawn with it. Those documents were fine.

My error, and the third of its kind today: I reasoned a confident conclusion from
an unverified premise, one paragraph after writing that the lesson was to
instrument rather than assume. Checking took one grep and I only ran it after
Jahni suggested it.

The line is marked TEMPORARY with removal instructions and a guide to reading the
result. Combined with the WORST-POINT DUMP already committed, one build now
separates the two possibilities cleanly:
  454 -> 0   : FP model was the cause; keeping precise then needs a profile,
               because it costs the vectorisation T2.a's SIMD work was buying.
  454 -> 454 : real logic difference; read the dump.

Either way the line comes back out afterwards.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Source/VoxelForge/VoxelForge.Build.cs

@@ -11,6 +11,33 @@ public class VoxelForge : ModuleRules
 		// UseExplicitOrSharedPCHs is the modern recommended setting
 		PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;
 
+		// ============================================================================
+		// ⚠️ TEMPORARY EXPERIMENT — 2026-07-27. REMOVE THIS LINE WHEN THE ANSWER IS IN.
+		// ============================================================================
+		// Testing whether the ~1 ULP residue between GetMazeDensity and its operator-stack
+		// port (VoxelForge.OpStack.MazeEquivalence: 454 of 20000 samples, 0 crossing the
+		// isosurface) is caused by the compiler being allowed to reassociate identical
+		// source differently per translation unit.
+		//
+		// FPSemantics is a PER-MODULE property. Setting it on the VoxelM game module does
+		// NOT affect this one — every line of density code lives in VoxelForge, so the
+		// switch has to be here to mean anything. (That mistake already cost one build and
+		// one wrong conclusion.)
+		//
+		// UnrealBuildTool's Windows default is /fp:fast ("Default is imprecise FP
+		// semantics", VCToolChain.cs); every Clang target defaults to precise instead.
+		//
+		// READ THE RESULT LIKE THIS:
+		//   454 -> 0    : the FP model WAS the cause. Then decide separately whether to keep
+		//                 precise (it costs vectorisation on the density hot path — the thing
+		//                 T2.a's SIMD noise work was buying — for an unmeasured amount).
+		//   454 -> 454  : the FP model is NOT the cause and the difference is real logic.
+		//                 Read the WORST-POINT DUMP the test now prints.
+		//
+		// EITHER WAY THIS LINE COMES BACK OUT once measured. Keeping /fp:precise on the hot
+		// path is a decision that needs a profile, not a leftover from a diagnostic.
+		FPSemantics = FPSemanticsMode.Precise;
+
 		// Modules we depend on:
 		// - Core: Basic types (TArray, FString, etc.)
 		// - CoreUObject: UObject system (UCLASS, UPROPERTY, etc.)