fix(highway_3d): stop the lane at the hit line

[topkoa]

Closes #991.

The bug

The lane maps chart time to z exactly the way notes do — z = dZ(t - now) — across the window [now - BEHIND, now + AHEAD]. That puts its near edge at +TS*BEHIND: half a second of lane sitting past the hit line, toward the player.

Nothing is ever drawn there. drawNote clamps every note with Math.min(0, dZ(dt)), and the chord frames do the same, so notes stop dead at z = 0. The strip past the line was therefore lane surface with nothing on it — the artifact in the issue screenshot.

The fix

Clamp the floor geometry's near edge to the hit line. That's it.

The far edge is deliberately untouched — it still lands at -AHEAD*TS, aligned with the note horizon. That matters: a previous fix (still commented in the code) widened the span to AHEAD + BEHIND precisely so the far edge would reach the horizon, because using AHEAD alone stopped it at -TS*(AHEAD-BEHIND) and left the last BEHIND seconds of notes with no lane underneath. So the sliced path keeps its AHEAD + BEHIND window and the clamp is applied per slice; a slice lying entirely past the line collapses to zero length and is skipped before the arpeggio probe, so it costs nothing.

Verified numerically, both lane paths now span exactly [-AHEAD*TS, 0]:

Path	Near edge	Far edge
Anchor / sliced	0.000000 (hit line)	-5.175000 = -AHEAD*TS
Fallback	0.000000	-5.175000

Why all four sites

Four places shared the identical + TS * BEHIND shift, and they're one invariant — highway floor geometry that should stop at the hit line:

1. Sliced/anchor lane (z0/z1 per slice) — also feeds both divider loops, so those are fixed for free.
2. Fallback lane quads (laneLen/zLane) — also feeds the arpeggio outer dividers.
3. Fallback plain dividers (divLen).
4. Fret boundary extension lines (extZMid).

#4 is included on purpose: those lines share the same expression, so fixing only the lane would leave fret lines poking past a lane that now stops — visually worse than the original. Happy to narrow it to the lane proper if that's preferred.

Notes

• Comment-heavy by design: the near/far asymmetry is exactly the kind of thing a future reader would "simplify" back into the bug, so the reason the span stays AHEAD + BEHIND is written down at the clamp.
• JS-only plugin change — no rebuild, no new deps, no settings, no API surface. node --check clean.
• Behaviour when Camera Director / splitscreen are active is unaffected; this is pure scene geometry.

🤖 Generated with Claude Code

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.