The range walks: its own movement tuning and hull through the engine’s solver #63

Today the range's own page says "you cannot move — you turn on the spot": the second game has a room coming (#50) and a solver arriving behind the door (#62), and this is the issue that lets a person walk down the lane on the range's own numbers, which is the sentence the whole direction is built to be able to say.

Done looks like

• [ ] src/range/movement.ts holds the range's own tuning — RANGE_MOVE and RANGE_HULL — and not one of Counter-Strike's numbers: deliberately different gravity, speed, acceleration and hull, each with a sentence saying why the range wants it that way. If a number matches CS's, say in the pull that it was chosen and not inherited.
• [ ] src/range/main.ts steps a body through RANGE_ROOM with the engine's move, handing in the range's tuning and hull at every call, and the intent already read from the engine's controls is what drives it: walk, strafe, jump, crouch, and the walk modifier.
• [ ] The eye follows the body through the engine's eyeHeight, and the shot in targets.ts traces from where the eye actually is rather than from a constant — so walking changes what you can hit, which is the point.
• [ ] You cannot leave the room: a body that runs at a wall stops at it, a body that walks off nothing falls and lands, and stuck never leaves a person inside geometry. Each of those three is a test.
• [ ] src/range/movement.test.ts runs headlessly and would fail without this: a second of forward input moves the body about as far as RANGE_MOVE's max speed says and not CS's, a jump's apex is v²/2g for the range's gravity, a crouch lowers the eye by the range's own amount, and the same seeded inputs from the same start put the body in the same place twice.
• [ ] The pin from #53 still holds, or it moves in this pull with a sentence saying what changed and why — a person walking is a change to the game, so if the digest covers the shooter's position it must be re-pinned deliberately, not quietly.
• [ ] src/range/independence.test.ts stays green: the tuning is the range's, the solver is the engine's, and nothing reaches into src/client/.
• [ ] The page stops saying you cannot move and says what the range's numbers are instead — heavier, slower, or whatever they turn out to be — and README.md's range section says both games run the same solver on different numbers, which is the proof the physics extraction was real.
• [ ] bun test green, static/range.<hash>.js rebuilt and committed with its ceiling held or raised with the measured number.

Files I expect to change

src/range/movement.ts, src/range/movement.test.ts (new), src/range/main.ts, src/range/targets.ts (the eye it traces from), src/range/pin.ts if the run's snapshot gains the body, src/pages/range.ts, README.md, static/range.<hash>.js.

Risks

This is the first time the engine's solver runs on numbers it was not written for, so expect it to pinch: if the mover needs a change to work for a second tuning, that change belongs in src/engine/physics.ts with a test in movement.test.ts under both profiles — never a range-shaped special case behind the door. The room from #50 must enclose the lane or a body will walk out of the world; that is #50's test, and if it fails here say so rather than patching around it. Keep the fixed step at the range's 50 Hz and do not borrow the shooter's 64.

Suggested: Vesper — the range is theirs from #24, and a person walking at 60 fps on a phone is the brief.