Expose clutch position scale as a constructor parameter (operator arm travel vs robot reach mismatch)

[johnnynunez]

Context

SO101ClutchRetargeter integrates controller deltas 1:1 (_CLUTCH_POSITION_SCALE is a constant 1.0). The operator's comfortable arm travel (~0.7 m) is roughly 2× the SO-101's reach (~0.35 m), so natural motion plus release-reengage cycles ratchet the commanded target out of the workspace within 2–3 re-engages.

Evidence

• Session CSVs: 85% of frames outside the reachable envelope; each clutch re-engage compounds the wind-up ("ratcheting").
• We validated a position-only scale locally (LeRobot example layer): pos = home + pos_scale * (grip - origin), orientation untouched (scaled rotation is disorienting and the 5-DOF wrist is soft anyway). 18 unit tests, including the motivating property: N mouse-lift cycles advance N·scale·δ instead of N·δ. End-to-end: 0.4 m controller motion → 0.2 m EE at scale 0.5.
• Hardware validation pending; runtime motion-scale control via thumbstick (HUD v2) builds on the same mechanism.

Proposal

Expose the clutch position scale as a constructor parameter (default 1.0, position-only, validated > 0 and finite). Operator-arm vs robot-reach mismatch is the norm for small/desktop arms, not the exception — every SO-101-class user needs this knob.

Happy to send the PR (the change is small and fully unit-tested on our side).

---

Part of the field-integration feedback series (SO-101 + reBot DevArm, June 29 – July 6). Priority suggestion: P1.