fix(rmw_wait): trigger the per-node graph guard conditions on graph change (rosbag2 late joiners)

[benaliabderrahmane]

Fixes #40.

Stacked on #42 (base is fix/registry-doorbell-wakeup, not devel). Review #42 first; this PR's own diff is its last three commits.

Problem

rmw_node_get_graph_guard_condition() returns the per-node guard condition created in rmw_create_node, and that is the object rclcpp's GraphListener actually waits on. The only trigger in rmw_wait fired ctx->graph_guard_condition instead — a context-level field that is declared and never assigned anywhere, so the branch was dead code and the object rcl waits on was never triggered. The loop just above it had an empty body and a comment claiming the node triggers its own guard condition, which nothing does.

So Node::wait_for_graph_change() never woke, for anyone. Everything built on graph events was blind to endpoints that appeared after it started:

• rosbag2 records nothing when the recorder starts before the publishers. Its topic discovery re-reads the topic list only when a graph event fires (wait_for_graph_change → check_and_clear). With no event, the recorder never subscribes — ros2 bag info shows 0 messages. Start the publishers first and the same command records fine.
• wait_for_service() could hang even though the service was up.
• wait_for_publisher-style helpers and on_graph_change callbacks never fired.

Plain pub/sub was unaffected, because a subscription declares its interest through the registry up front and never needs a graph event. That asymmetry is why this went unnoticed for so long: everything works except the watch-the-graph machinery.

Fix

The context keeps a mutex-guarded list of every node's graph guard condition:

• rmw_create_node appends as its last step, so no earlier failure path has to undo it.
• rmw_destroy_node removes the entry under the same mutex before destroying the guard condition, so the trigger loop can never fire a freed object.
• When rmw_wait observes a registry generation change, it triggers every guard condition in the list.
• The now-orphaned UdsContext::graph_guard_condition field is removed.

A wait set holding only guard conditions — GraphListener's exact shape — is woken by the registry doorbell from #42, re-runs the generation check, triggers its own guard condition and reports it ready. So graph events work with no data traffic on the domain at all.

End-to-end: ros2 bag record started before the publisher

Real rosbag2, recorder up 4 s before ros2 topic pub appears, ROS 2 Jazzy:

build	result
devel	recorder aborts after 209 ms — rcl_wait unexpectedly timed out in the GraphListener thread
#42 alone	survives, but never subscribes → 0 messages recorded
#42 + this PR	subscribes → 91 messages recorded over 9 s

Tests

NodeGraphGuardConditionTriggersOnGraphChange blocks a thread on the node's graph guard condition alone — rosbag2's discovery shape — then creates a subscription from another thread and asserts the wait wakes with the guard condition ready.

The third commit hardens that test. As first written it passed even with the doorbell wake path deleted: the fixture's own rmw_create_node leaves an unconsumed registry generation edge, so the waiter's first rmw_wait triggered the guard condition and found it already ready at the top-of-wait check, returning before it ever blocked. That proved only that a pending edge triggers the guard condition — not the property rosbag2 depends on. It now drains pending edges until a wait genuinely blocks and times out, then asserts the blocked wait both woke early and had really been blocked across the 200 ms before the subscription appeared.

Verified three ways:

variant	result
parent commit (#42's tip)	fails — 3 s timeout, guard condition never triggered
this PR with register_fd(doorbell_fd) commented out	fails — blocks the full 3 s (proves the test really blocks)
this PR as-is	passes — wakes ~200 ms in, i.e. on the graph change

Full suite green on Jazzy — 129 tests. Compiles clean against Kilted headers locally; CI green on Jazzy, Kilted and Rolling.

Note

Because this PR's base is #42's branch rather than the default branch, GitHub will not auto-close #40 on merge. Once #42 lands on devel, retarget this PR's base to devel (which also gives it PR-triggered CI); close #40 when both have reached main.