fix(cliffs): the collision box is the RAW rectangle - #88 was wrong (#84)

[wormeyman]

Disassembly, prompted by flagging #88's fix as the thing I was least confident about. That flag was right: #88 scored best on every metric and was wrong about the mechanism.

What the engine actually does

It does not collide against rotbb's rectangle rotated 45°. It uses the raw stored rectangle and discards the orientation tag:

1. EntityMapGenerationTask::tryToAddCliff (0x101625038) loads the box from proto + 0x5c0 + id*0x48 (20 bytes: four int32 edges at +4, orientation word at +0x14) and calls wouldCollide with Direction = 0 — literally mov x4, #0x0.
2. wouldCollide (0x101625468) forwards box and direction to BoundingBox::BoundingBox(BoundingBox const&, Direction) (0x101c04380), then floors with (box + position) >> 8 over an inclusive tile rect.
3. That constructor zeroes the destination, writes sentinel 0x80010000 into the destination's orientation word, and dispatches through a jump table whose entry 0 is 0 (read at 0x102d01400) — the identity arm, copying left_top/right_bottom verbatim. The source orientation is never read; the rotate arm is reachable only for a non-zero Direction.

Corroborated by the API mirror rather than disassembly alone: BoundingBox is documented as {MapPosition, MapPosition} or {..., RealOrientation} with orientation optional, and OrientedCliffPrototype::collision_bounding_box is a plain BoundingBox.

Three shapes, and the best-scoring one is wrong

box	false rejections	recall	precision	evidence
AABB (until #88)	13	0.9675	0.9743	an assumption
45° oriented rect (#88)	0	0.9758	0.9727	empirical fit only
raw stored rect (this PR)	6	0.9720	0.9713	disassembly + API docs

The middle row is the trap. It shrank the box past the engine's, and the excess shrinkage absorbed a different defect: 4 of the 6 cliffs the correct box still rejects are cells where our orientation disagrees with the game's, so we load the wrong box entirely. Those 4 belong to the standing orientation residual and should stay visible. A model that scores perfectly by hiding a second bug is worse than one that leaves it exposed.

Also

• test/cliffOrientation.spec.ts asserted the opposite of this until now, on the stated reasoning that the AABB "is what the engine ends up scanning". Rewritten: the shipped box is the raw rectangle, it depends on intersect (the old file asserted independence), and its area is at most half the AABB's — though it is not contained in it, since a small intersect pushes hx past size/2. My first attempt asserted containment on every axis and failed for exactly that reason.
• cliffBoxCoversTile and the separating-axis narrow phase are deleted. The broad phase alone is the whole rule, which is what the engine does.
• Edges quantised to 1/256 — MapPosition is 8-bit fixed point, so x_dist's sqrt(2) cannot reach the engine at full precision.
• Supersedes docs(cliffs): shipping orientation is 2.4%, not 2.0% (#84) #89, which was correcting a figure that has since moved again.

pnpm run verify green: 1311 passed / 3 skipped, 0 warnings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WRKSNgkidxc6daeHGJHqpt