feat(oracle): the resource lever moves TILES - confounded, but inert for cliffs (#84)

[wormeyman]

Every ore result in #84 uses one instrument: switch a resource off through map_gen_settings.autoplace_controls and see which cliffs come back. It has been treated throughout as removing entities and nothing else. It does more, and the game's data files say so.

-- planet-vulcanus-map-gen.lua
vulcanus_calcite_size   = "slider_rescale(control:calcite:size, 2)"
vulcanus_calcite_region = "... vulcanus_calcite_size ..., control:calcite:frequency ..."

-- tiles-vulcanus.lua
volcanic_jagged_ground_range = "5 * min(10, max(vulcanus_calcite_region + 0.2, ...))"

That last one is a tile range, so calcite size = 0 changes which tile the argmax picks - a live route from the lever to Surface::wouldCollide's TILE half, exactly the kind #124 was left looking for after it closed the entity half.

Measured against the game

Three arms over [1500,1500], uniform stride-2 grid, 16384 points:

arm	tiles changed	blocking gained	blocking lost
calcite OFF	841 (5.1%)	0	0
ALL resources OFF	1066	0	0

Every change is ground-to-ground - volcanic-jagged-ground losing the argmax to -folds, -folds-warm, -soil-dark, -soil-light, -folds-flat. Only lava and lava-hot carry tile_collision_masks.lava(), and nothing crosses that boundary, so constCollideWithTile cannot see any of it.

Every ore result in #84 stands. But the instrument was mischaracterised, and anyone reaching for autoplace_controls for a new question needs to know it moves tiles.

Non-vacuity: 1682 of the 16384 sampled tiles are blocking, so there was a boundary to cross; and each arm records the autoplace_controls the SURFACE read back, so "no tile moved" cannot be confused with "the override never applied".

Our port reproduces it, which covers the unsampled tiles

The capture is a 25% sample. Our tile model answers over all 65536 and says 3335 changed, 0 blocking - a rate of 5.09% against the game's 5.13%, on a lever nobody had ever pointed at it. That corroborates the port independently and is what lets its "no blocking flip anywhere" cover the 75% the grid skipped.

Control: tungsten OFF moves zero tiles here - there is no tungsten in this region; it is what fills [0,0], where #126 measured the ore suppressing zero cliffs.

Where this leaves the mechanism - a three-way contradiction

Both halves of Surface::wouldCollide are now closed against the ore:

half	closed by
entity	#124 - disjoint masks at prototype level, ordering, applyEntities skipping rather than destroying
tile	this PR, on the game's own data

And yet #124 also found the ore acting at the destroy stage, where wouldCollide is the only thing that destroys. All three cannot be right. Recorded rather than smoothed over, ranked by corroboration:

1. entity half closed - three independent routes, one a prototype-level data fact. Strong.
2. tile half closed - the game's own tiles, non-vacuity arm, corroborating port model. Strong, but a 25% grid.
3. ore acts at the destroy stage - n = 1. Weakest, and the first place to look.

Note that one cell, 1546,1550.5, is also one of the six #125's cascade does not explain. It has now been anomalous twice.

Harness

sampleTileNames gains an autoplaceControls override, plus a sampleTileNamesFull sibling returning the controls the surface read back (the existing signature is unchanged and now delegates). New fixture is deliberately a uniform grid rather than the positions our port predicts will change, so it does not encode the model it exists to check. PROVENANCE.json entry added; capture takes ~7s.

Verification

pnpm run verify green - 1478 app (up 9) + 13 worker + 3 container tests, 0 warnings, exit 0. Nothing shipping changed.

🤖 Generated with Claude Code

https://claude.ai/code/session_015jeznBmWiZywUc7cBw9xFU