### Fix: `ReachyMiniDriver`'s movement RPCs refuse a motion argument the robot cannot be commanded with

`look`, `antennas` and `body` carry nine caller-supplied numbers into a command dict and hand it to the active hardware link, and nothing downstream refused them. Both links serialize that dict as JSON, and Python's encoder emits `nan` / `inf` as the bare tokens `NaN` / `Infinity`, which RFC 8259 does not define: the frame reaching the daemon was not valid JSON, so it was either rejected whole -- losing a command the RPC had already reported as `success` -- or parsed leniently, handing a non-finite target to the servos. Because `rpy_to_pose` is pure trigonometry, the same unusable argument also behaved differently depending on which parameter it landed in: an `inf` angle raised `ValueError: math domain error` out of `math.cos` and past the RPC, while an `inf` offset was divided by 1000 and reported as a successful move. A `True` was honored as a silent one-degree command, and a numeric string, `None` or a list raised a bare `TypeError` naming neither the RPC nor the parameter.

All nine now share `strands_robots.utils.finite_number_error`, the existing domain for a signed physical quantity a command carries verbatim to a robot -- already applied by the `drive(linear, angular)` of every mesh bridge. An unusable argument is refused with a `{"status": "error", "reason": ...}` naming the RPC and the parameter, before anything reaches the link. Both signs and zero stay valid, and the reachable workspace remains the daemon's to enforce.
