A gripper_cmd goal succeeds against stale state while the serial link is faulted

[ebarnett3]

On a faulted link, robotiq_driver keeps the last good status block in its state interfaces and returns OK from read(), with a throttled warning that the position may be stale. The gripper action controller reads that frozen position and reports success against it.

Bench, 2026-09-16, 2F-85 at 500 Hz on Jazzy: with the USB adapter unplugged for over a minute and the driver logging "link is Faulted; the reported position may be stale" every 5 s, a gripper_cmd goal to close (position: [0.79]) returned SUCCEEDED while the gripper had not moved and /robotiq_gripper_status_broadcaster/status kept repeating the pre-unplug reading.

A client has no signal that the success was fake: neither the action result nor the status topic carries link state.

Options, not mutually exclusive:

• The driver returns return_type::ERROR from read() while the link is not Operational, which makes the controller manager deactivate the controllers, so goals are rejected rather than granted. This is the behaviour the stock parallel_gripper_action_controller expects from hardware that cannot answer.
• The driver exports a link-state interface, and the gripper controller aborts an in-flight goal when it drops. This needs a Robotiq-specific controller or an upstream change.
• Wait for the SDK's augmented status (timestamp, connection state) from Connect with retry and reconnect after link loss grippers#33 and expose it on the status topic, so a client can check before trusting a result. This helps clients but does not stop the false success itself.

The first option is the smallest change and matches how ros2_control models unreachable hardware; the cost is that a brief link hiccup deactivates everything until the operator reactivates. Decide which trade-off the driver should make, then document it in the README's hardware section.

Related: robotiq/grippers#33 (reconnect after link loss).

[ebarnett3]

Partly changed by #100: with use_object_status on, a goal sent while the link is faulted no longer succeeds, since the frozen object status never changes and the goal aborts after object_status_timeout (10 s) with both flags false, unless the stale position already lies within goal_tolerance of the target. The false success is gone in the common case; the missing link-state signal, and the 10 s wait, remain as described here.