fix(executor): wake executor when future is set by non-executor thread (#1916)

[aki1770-del]

Problem

spin_until_future_complete with no timeout (-1) blocks indefinitely when the
future is fulfilled by a thread that is not part of the executor.

Root cause (executor.hpp / executor.cpp):

• spin_until_future_complete_impl(-1ns) passes the full remaining timeout to
  spin_once_impl, which calls wait_for_work(-1ns) → wait_set_.wait(-1ns)
• wait_set_.wait blocks until a registered entity (subscription, timer, service,
  client, or guard condition) becomes ready
• A future fulfilled by an external thread triggers none of these entities
• The executor never wakes; wait_for_work never returns

This was originally reported alongside a potential GuardCondition callback bug
(#1917), but that path was subsequently fixed. The remaining issue is that the
executor has no mechanism to learn the future is ready when it is set externally.

Fix

Spawn a watcher thread inside spin_until_future_complete that monitors the
future and triggers interrupt_guard_condition_ the moment the future is set.
This immediately unblocks wait_for_work without busy-waiting in the executor's
main loop.

The watcher uses future.wait_for(100ms) in a loop (rather than future.wait())
so it can observe a stop_watcher flag set on all exit paths — enabling a clean
join() whether the spin returns by success, timeout, cancel, or exception.

Files changed:

• rclcpp/include/rclcpp/executor.hpp — expand spin_until_future_complete
  template; add #include <thread>
• rclcpp/test/rclcpp/executors/test_executors.cpp — add
  testSpinUntilFutureCompleteExternalThread regression test

Prior work consulted

• spin_until_future_complete may block forever if nothing wakes the executor after the future completes #1916 — original issue (spin_until_future_complete blocks forever)
• GuardCondition should have a callback that gets handled by the executor #1917 — GuardCondition callback enhancement; executor wakeup discussion
• Make lifecycle demo automatically exit when done demos#558 — wjwwood's suggested user-level workaround
• Keep callback-group guard conditions alive in Executor #3114 — related: ExecutorEntitiesCollector guard condition lifetime fix

The watcher-thread approach is consistent with the interrupt_guard_condition_
pattern already used in Executor::cancel() (executor.cpp L472) and
Executor::handle_updated_entities() (executor.cpp L146).

Source reading

• rclcpp/include/rclcpp/executor.hpp L571 — interrupt_guard_condition_ declaration
• rclcpp/src/rclcpp/executor.cpp L265–314 — spin_until_future_complete_impl
• rclcpp/src/rclcpp/executor.cpp L913–930 — get_next_executable → wait_for_work
• rclcpp/src/rclcpp/executor.cpp L758–787 — wait_for_work → wait_set_.wait
• rclcpp/src/rclcpp/guard_condition.cpp L69–85 — trigger() already calls
  rcl_trigger_guard_condition before callback (sloretz's 2022 bug was separately fixed)

AI-assisted — authored with Claude, reviewed by Komada.