Camera jump ROOT CAUSE: frame() ran OrbitControls.update() in follow mode

The jump was never occlusion: endless re-frames the camera on every
segment build (ensure -> cams.frame(box), meant for orbit + far-plane),
and frame() ended with controls.update(). OrbitControls.enabled gates
INPUT, not update() — update() unconditionally snaps camera.position to
the orbit spherical around the freshly-set box center. So every stream
LOAD EVENT yanked the follow cam to the orbit 'default angle' and the
follow lerp floated it back — exactly the user's words, on any terrain.

Found by instrumentation (dev handle __session + __ctx camera probes):
19 jump events in 3 sim-minutes, each a ~60u teleport with a 0.39/100ms
decay tail, each coinciding with a built-window change; samplePoint and
the marble were continuous throughout. After gating ALL orbit-side
effects (target/position/lookAt/update) behind mode==='orbit':
0 events in 3 sim-minutes. Orbit toggle unaffected (same path).

Hardening kept from the same hunt:
- Island occluders are MASS meshes only (cliff blocks + caps) — a tree
  frond crossing the sightline no longer pulls the boom in.
- Thin obstructions (< 1.6u blocked span, measured by a reversed cast)
  never trigger pull-in: arches/rails/grazes read better as a brief
  clip-through than a boom teleport; a far end inside a mass stays
  thick (the anti-clip guarantee).
- Genuine subject teleports (respawns) now CUT to the fresh framing
  (lookInit reset + position snap) instead of lerping across the world
  through whatever stands in between.
154 tests, check clean.

commit

0f1080aae7dc216188cbd12ac44594608e353762

parent

590d93c728676400e61502f49982031a10e0c136

author

Dami <dami.etoile@gmail.com>