src/limits-search.ts steps one joint's speed and acceleration up until p95 error or overshoot worsens, then backs off one step - orchestration and test only #494

Piece 1 of 2 of #469, the part a builder can do without the real arm. It follows the shape of src/tuning-run.ts (#485).

Done when:

• [ ] Software/so101/src/limits-search.ts exports searchLimits({ joint, steps }, deps). deps is { isIdle(), sweep(joint) → { p95Error, overshoot, timeToArrive }, readLimits(joint) → { speedDegS, accelDegS2 }, writeLimits(joint, { speedDegS, accelDegS2 }) }. steps is an ascending list of { speedDegS, accelDegS2 } pairs, each inside the RANGES in src/safety.ts; a step outside them is refused before anything moves.
• [ ] It refuses to start when isIdle() is false. It sweeps at today's limits, then writes each step and sweeps again. It stops at the first step where p95 error or overshoot is worse than the best so far, and writes back the last good step (today's limits if none was good).
• [ ] On any throw (STOP, E-stop, someone starts driving) it writes back the limits it read at the start and rethrows.
• [ ] It returns { joint, from, to, runs: [{ step, result }], at }, which is plain data that a report can print.
• [ ] limits-search.test.ts, with a fake deps, covers: refused while driving; a step outside the ranges refused before any write; the search stops at the first worse step and keeps the one before it; nothing good means today's limits are written back; a throw mid-search puts the starting limits back.
• [ ] Only the two new files. forge.json is untouched, and bun --cwd Software/so101 test passes.