Retire examples/rosCompose: moved to its own library, OneMachine

Per Rui's call: rosCompose grew beyond a HAPI example (topic pub/sub,
QoS, services, actions, its own test/example needs) and duplicating its
four headers between here and OneMachine would only drift. The headers
(transport.h, qos.h, service.h, action.h), unchanged, now live at
OneMachine/include/oneMachine/rosCompose/; node_avr.cpp/qos_decorators.cpp
move there too whenever OneMachine gets its own examples/.

docs/rosCompose.md and docs/INDUSTRY.md updated to point at OneMachine
instead of a now-deleted examples/rosCompose/.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: neu-rah

docs/INDUSTRY.md

@@ -135,7 +135,7 @@ HAPI models protocol layers as compile-time components. The complete protocol st
 
 ### Robotics & Autonomous Systems
 
-**Status: Partially demonstrated.** Motion control and sensor fusion are real: a compile-time-composed motor-control integration has been verified on real hardware, and a sensor-fusion pipeline has been verified on AVR (`examples/iotComposition`). The composition *surface* of a robotics middleware has also been mapped: [`examples/rosCompose`](../examples/rosCompose/) assembles a ROS-shaped node — topic pub/sub, a service, an action, with QoS decorators — from HAPI primitives, reducing ROS 2's `rclcpp`/`rcl`/`rcl_action`/`tf2` composition surface (read from source) to three existing primitives plus two new fixed-capacity buffers ([`docs/rosCompose.md`](rosCompose.md)). That is a structural result — the types compose with no vtable, heap or dispatch of their own — not a live-transport or ROS-interop claim, and it is explicitly scoped to single-loop embedded targets (multi-threaded executor scheduling is out of scope). Industrial robotics and CNC controllers as complete systems are unbuilt extrapolations from that work, not separately verified. **Autonomous vehicles is a materially larger claim than either** — full perception/planning/control stacks, not a single composed control loop — and additionally carries the certification barrier described above; listing it alongside motion control understates the gap between them.
+**Status: Partially demonstrated.** Motion control and sensor fusion are real: a compile-time-composed motor-control integration has been verified on real hardware, and a sensor-fusion pipeline has been verified on AVR (`examples/iotComposition`). The composition *surface* of a robotics middleware has also been mapped: [rosCompose](https://github.com/InternetOfPins/OneMachine), now its own library (moved out of this repo's examples/), assembles a ROS-shaped node — topic pub/sub, a service, an action, with QoS decorators — from HAPI primitives, reducing ROS 2's `rclcpp`/`rcl`/`rcl_action`/`tf2` composition surface (read from source) to three existing primitives plus two new fixed-capacity buffers ([`docs/rosCompose.md`](rosCompose.md)). That is a structural result — the types compose with no vtable, heap or dispatch of their own — not a live-transport or ROS-interop claim, and it is explicitly scoped to single-loop embedded targets (multi-threaded executor scheduling is out of scope). Industrial robotics and CNC controllers as complete systems are unbuilt extrapolations from that work, not separately verified. **Autonomous vehicles is a materially larger claim than either** — full perception/planning/control stacks, not a single composed control loop — and additionally carries the certification barrier described above; listing it alongside motion control understates the gap between them.
 
 Robotic systems are built from deterministic processing pipelines:
 

docs/rosCompose.md

@@ -2,10 +2,14 @@
 
 > **Status: Demonstrated (structurally).** A local scouting exercise read
 > ROS 2 (`rclcpp`, `rcl`, `rcl_action`, `tf2`) from source and mapped its
-> composition surface onto HAPI's primitive set. The buildable result is
-> [`examples/rosCompose/`](../examples/rosCompose/). No live DDS / socket
-> round trip was verified — this is a claim about how the *types* compose
-> and what the generated code contains, not about ROS interoperability.
+> composition surface onto HAPI's primitive set. The buildable result
+> (`transport.h`/`qos.h`/`service.h`/`action.h`) has moved to its own
+> library, [OneMachine](https://github.com/InternetOfPins/OneMachine)
+> (`include/oneMachine/rosCompose/`) — no longer a HAPI example, so it
+> can carry its own examples and tests without living inside this repo.
+> No live DDS / socket round trip was verified — this is a claim about
+> how the *types* compose and what the generated code contains, not
+> about ROS interoperability.
 
 ROS was used as a **reference oracle only** — a well-specified, widely
 understood example of "typed multi-endpoint device structure with a