The nine surviving src/noise/ math modules are held by the expression layer, not by Fulgora's renderer

[wormeyman]

#227's done-when says src/noise/ ends up holding "orchestration and catalogs
only". Nine math modules are still at its top level, so that is not met.

It is easy to read #363 as the thing that frees them, because #363 is the last
piece of app rendering still on TypeScript. It is not. Closing #363 would
leave all nine exactly where they are. This issue records why, so the next
attempt starts from the real reason.

What is actually importing them

Measured 2026-08-31 on main at a9e764f, counting importers under src/
only - the app and library code, not the specs - with:

grep --recursive --files-with-matches --extended-regexp \
  'from "[^"]*/MODULE"|from "\./MODULE"' src/

module	src/ importers	of those, outside src/noise/
multioctaveNoise	8	none
distanceFromNearestPoint	7	src/model/elevationPreviewCtx.ts
basisNoise	4	none
fastApprox	3	none
spotCandidates	3	none
taus88	3	none
spotSelection	2	none
voronoiNoise	2	none
basisGradientTable	1	none

Why #363 frees none of them

#363 moves Fulgora's "all" render from TypeScript to the engine. The importers
above are somewhere else entirely:

• The surviving expression layers. expressions/vulcanus*.ts,
  expressions/fulgora*.ts and tiles/vulcanusCatalog.ts account for most of
  the count. They survive Port phase 7: cut over and delete the TypeScript math #227 on purpose.
• The eval core. eval/primitives.ts imports basisNoise and
  eval/ctx.ts imports distanceFromNearestPoint.
• The placement layer. placement/placementRoll.ts imports taus88.
• App model code. src/model/elevationPreviewCtx.ts imports
  distanceFromNearestPoint. That one is not under src/noise/ at all.
• Each other. basisNoise imports taus88 and basisGradientTable;
  multioctaveNoise imports basisNoise and fastApprox; spotSelection
  imports spotCandidates and fastApprox; voronoiNoise imports
  fastApprox.

Not one of those paths runs through renderFulgoraTerrain or
renderFulgoraResources.

So what would it take

Open question rather than a plan, which is why this is filed rather than done.
The nine are not dead code that a renderer is pinning; they are the arithmetic
the surviving expression layer is written in. Removing them means deciding what
that layer is FOR now that no planet renders through it, and the honest answers
seem to be:

1. Keep them. Treat the TypeScript expression layer as the reference
   implementation the Rust port is graded against, and rewrite Port phase 7: cut over and delete the TypeScript math #227's done-when
   to say so. The tier-1 fixtures and the oracle specs already use it this way.
2. Delete the expression layer too, and re-point every spec that reads it at
   the engine. Much larger than it looks - test/oracle/oracle.spec.ts and the
   wasm*Parity specs are the ones that would move.

Option 1 may already be what the repo does in practice. If so the fix is a
documentation change, not a deletion, and #227's done-when is the thing that is
wrong.

Related

• Port phase 7: cut over and delete the TypeScript math #227 - the port's phase 7, whose done-when this is about.
• Fulgora's default view renders entirely in TypeScript, so #227's done-when is not met #363 - Fulgora's "all" render, which is worth doing on its own terms and
  does not touch this.