Validate on a 2F-140, and decide whether to ship a Hand-E description

[ebarnett3]

All hardware testing behind v1.1.0 ran on a 2F-85. Two model-coverage gaps remain.

2F-140 — description ships, never run against hardware

robotiq_description/urdf/2f_140.ros2_control.xacro exists with gripper_closed_position:=0.695, and the 2F-140 is listed as supported, but nothing has driven one. Worth confirming:

1. Activation and the calibration sweep complete.
2. Position, speed and force goals behave; in particular that gripper_closed_position 0.695 maps the full stroke — a wrong closed position shows up as goals that saturate before the fingers do, or fingers that stop short of the commanded position.
3. reactivate_gripper recovers from a fault.
4. use_dummy and use_fake_hardware still come up with the 2F-140 description.
5. The C++ SDK directly, via examples/move_gripper — expected to work unchanged since the register map is shared across the family, but unverified.

Hand-E — no description ships

There is no Hand-E URDF/xacro, no ros2_control config and no launch wiring in this repo; robotiq_control.launch.py defaults to the 2F-85. The driver itself is model-agnostic — it needs a serial link and gripper_closed_position — so a Hand-E works today if you supply your own description, and the v1.1.0 notes say exactly that.

The open question is whether to ship one. If yes, note that the Hand-E is a parallel-stroke gripper rather than a knuckle linkage, so the joint model is not a copy of the 2F descriptions with different numbers.

When testing

Per #29, every motion goal currently reports stalled: true / reached_goal: false even when the gripper reaches the commanded position. Judge motion by the joint position in /joint_states against your tolerance, not by the action result flags.