feat(cliffs): port fixImpossibleCells - and falsify the claim it explains Nauvis's residual

[wormeyman]

CellEdgeCliffCrossingArray::fixImpossibleCells (0x10160c550) ported. The headline result is negative, and it's the reason this is worth landing even though the numbers barely move.

It does not explain Nauvis's residual

Since 2026-07-20 cliffs-NOTES.md has stated Nauvis's ~6% cliff residual "is fixImpossibleCells". With the pass ported, Nauvis's cell sets are identical with it on and off, at both oracle seeds - 0.9433/0.9433/1.000 and 0.9423/0.9423/1.000 either way. It never fires there: cliffiness_nauvis is a hard 0-or-10 gate, so the configurations it produces are already legal.

That attribution was a guess recorded as a finding, and it survived eight days of being the "known cause". The remaining named candidate from the original disasm is tryToAddCliff's wouldCollide rejection, which has never been tested on either planet.

The 2026-07-20 decision to defer the pass was still right on the evidence available - deferring it cost Nauvis nothing.

The rule

A single forward sweep over one chunk's 8x8 cells (row-major, cy outer), not a fixpoint - clearing an edge changes the two cells sharing it, and visited cells are never revisited. Per cell it clears edges until the code is legal, taking the first clearable edge in order L, T, R, B, where clearable means not on the chunk's outer boundary. That boundary rule keeps the pass chunk-local, so the port needs no chunk ordering and worker tiling stays byte-identical (tiledEquality.spec.ts passes unchanged).

Legality needs no new table. The disasm splits on code <= 0x50 (0x51-byte jump tables at 0x102d00115 / 0x102d00166, two branches encoding the same accept/reject split) and code >= 0xC0 (bitmask 0x0001000000001003, set bits 0/1/12/48 → 0xC0, 0xC1, 0xCC, 0xF0). Extracted and compared against CLIFF_PLACED_TABLE: the accepted set is exactly isCliffPlaced(code) plus code 0.

Two corrections to the old note while here:

• It does not zero the whole chunk border. The bool gates zeroing the outer edges of the four corner cells only, and crossingsForChunk passes false (mov w1, #0x0 at 0x10160d0c8) - that step never runs in this path.
• The binary is a universal Mach-O. Raw reads of those jump tables need the arm64 slice offset added or they silently return x86_64 bytes. My first extraction did exactly that and produced 47 plausible-looking distinct targets instead of 2 - a failure mode that looks like data, not like an error.

Effect, measured

	recall	precision	ratio
Nauvis, both seeds	unchanged	unchanged	unchanged
Vulcanus [0,0]	0.788 → 0.792	0.684 → 0.685	1.152 → 1.155
Vulcanus [1500,1500]	0.855 → 0.870	0.718 → 0.719	1.192 → 1.210
Vulcanus [-1200,800]	0.801 → 0.803	0.865 → 0.866	0.925 → 0.928

Small and one-sided: recall up everywhere (+1.5 points at best), precision a shade up, count a shade worse. Costs ~10% on the cliff pass (6.15s → 6.77s over placedCells(0,0,1024,1024) on Vulcanus, paired runs), because the chunk path evaluates every edge of every chunk overlapping the query box rather than only the cells asked for.

This is a marginal change and I'd understand dropping it - the case for merging is faithfulness (the game runs this unconditionally) plus the falsified attribution, not the numbers. The case against is 10% for +1.5 points of recall at best. Happy either way.

Defaults to ON, because the game runs it unconditionally - deliberately unlike smoothing, which defaults to Nauvis's 0 rather than the prototype's 1.

Tests

test/cliffFixImpossibleCells.spec.ts pins the Nauvis no-change result (cell sets, not counts), proves the pass is not a global no-op by asserting it does fire on Vulcanus - without which "no change on Nauvis" would be equally consistent with the port doing nothing - pins the default, and pins the code-table correspondence.

pnpm run verify: 1175 passed, 0 failed.

🤖 Generated with Claude Code

https://claude.ai/code/session_016vZjgASLZyxUfXx1dsq2HX