Fix recovery cmd_vel hold behavior

[xbattlax]

Summary

Fixes #32.

• keep the active recovery Twist and re-publish it on each 20 Hz timer tick until the step deadline
• clear held motion state on stop, safety pause, reset, timeout, and external behavior result paths
• add a separate completion timeout for delegated commands such as clear_costmap, so the 0.1s nominal step duration is not reused as a service-result timeout
• add regression coverage for the node adapter with lightweight ROS message/module stubs, plus a core test for delegated command timeout behavior
• update the xbattlax recovery-safety README with the new guarantees

Verification

• PYTHONPATH=contributions/recovery-safety/xbattlax/oomwoo_recovery_safety pytest contributions/recovery-safety/xbattlax/oomwoo_recovery_safety/test
• git diff --check
• python3 -m compileall contributions/recovery-safety/xbattlax/oomwoo_recovery_safety/oomwoo_recovery_safety

[makers-pet]

Thank you again, xbattlax!

[makers-pet]

@xbattlax , I've given /cmd_vel holding a bit of a thought - it would be great to generalize health monitoring to any component. Can you please take a look at https://github.com/makerspet/oomwoo/tree/main/contributions/health-monitor ?

[xbattlax]

Thanks, I took a look and opened #36 as a first health-monitor contract/prototype.

It keeps /cmd_vel holding as a local motion-quality fix, but moves the robot-wide safety path into a general stack-health deadman: expected critical components publish work-path heartbeats, the monitor checks the active roster, and only then emits one MCU-facing stack heartbeat.

Verification is in the PR body.