fix(rmw_event): validate handles and set an error message on the failure paths

[benaliabderrahmane]

Description

Finishes the event API surface that #61 started. #61 made *_event_init reject
unsupported event types, which is the refusal rclcpp handles cleanly. The
remaining entry points were still bare stubs, and two of the gaps stay reachable:

• rmw_event_set_callback returned RMW_RET_UNSUPPORTED without setting an
  error message. That missing message is the ": error not set" half of the
  original EventsExecutor crash report, and it is what made the failure hard to
  place. rclcpp can no longer reach this function, but a failure code with
  nothing behind it is a dead end for anyone calling it directly.
• rmw_take_event validated neither its handle nor its implementation
  identifier, unlike the endpoint and node entry points elsewhere in this RMW.

RMW_CHECK_TYPE_IDENTIFIERS_MATCH now guards five entry points that were
missing it: both *_event_init functions, rmw_take_event,
rmw_event_set_callback and rmw_subscription_set_on_new_message_callback; the
service and client callback setters already had it.

One deliberate omission worth a look during review: rmw_event_fini is left
validating nothing at all — a bare (void)event; return RMW_RET_OK;. An earlier
revision of this branch did guard it, and the guards came back out: rcl_event_fini
skips the call entirely when event->impl is NULL, and that is exactly what
rcl_*_event_init leaves behind, since it deallocates impl and nulls it before
returning our RMW_RET_UNSUPPORTED. So no rejected init ever reaches this
function, and neither does a foreign handle — the guards were defending a state
the stack cannot produce, which is CLAUDE.md's "no error handling for impossible
scenarios". There is nothing to release either: rmw_event_t::data aliases the
endpoint's impl struct, owned by rmw_destroy_publisher /
rmw_destroy_subscription. The function carries a comment saying so.

Also adds an ## [Unreleased] / ### Fixed section to CHANGELOG.md covering
the above.

Is this user-facing behavior change?

Yes, in three ways, all narrow:

• A failing rmw_event_set_callback now leaves an error message, so rcl logs
  something useful instead of error not set. It also now returns
  RMW_RET_INVALID_ARGUMENT for a null handle and
  RMW_RET_INCORRECT_RMW_IMPLEMENTATION for a foreign one, where devel
  returned RMW_RET_UNSUPPORTED for both.
• rmw_take_event returns RMW_RET_INVALID_ARGUMENT /
  RMW_RET_INCORRECT_RMW_IMPLEMENTATION on misuse that previously returned
  RMW_RET_OK, and both *_event_init functions return
  RMW_RET_INCORRECT_RMW_IMPLEMENTATION for a foreign endpoint where devel
  fell through to the unsupported-type check and returned RMW_RET_UNSUPPORTED.
  Only reachable by passing a null or a foreign handle.
• rmw_subscription_set_on_new_message_callback returns
  RMW_RET_INCORRECT_RMW_IMPLEMENTATION for a foreign subscription, where
  devel would have cast that subscription's data to
  rmw_uds::UdsSubscription * and locked its callback_mutex.

rmw_event_fini is unchanged: it still returns RMW_RET_OK for every handle.

No event type becomes supported. rmw_event_type_is_supported still returns
false for all of them.

How was this tested?

test/test_rmw_event.cpp grows from 2 tests to 9. Three of the nine fail on
the current devel behavior and pass after this change:
EventInitRejectsForeignEndpoints, TakeEventRejectsBadArguments,
EventSetCallbackReportsUnsupportedWithAMessage. The remaining six also
pass on devel — including EventFiniIsANoOp, which pins the contract
devel already had.

The two existing tests are broadened to iterate 0 .. RMW_EVENT_INVALID rather
than naming two event types by hand. rmw_event_type_t has no explicit
initializers, so both the ordinals and RMW_EVENT_INVALID shift as upstream adds
event types — no ordinal is hardcoded anywhere.

Full suite green locally on jazzy: 163 tests, 0 failures. kilted, rolling and
lyrical are on CI.

Did you use Generative AI?

Additional Information

Independent of the other branches in this series — can merge in any order.