[TomCC7]

The existing ROSTransport(topic, MessageType) and ROS conversion helpers now accept registry-owned generated values. They resolve the corresponding installed ROS message class and convert through rclpy.serialization CDR; explicitly legacy classes keep their separate existing conversion path. No runtime code generation, package installation or ROS build is performed.

Parent: #4711. Message encoding refactor. This is a prerequisite for the shared whole-body adapter / R1 paths that still require wire conversion.

Wrong generated class identities and mismatched ROS target/source types fail before serialization. ROSTransport rejects a wrong declared generated value before starting ROS, and now retains its node/options when pickled.

Category	Files	Added	Removed
Existing transport/conversion implementation	3	67	26
Generated bridge/identity/lifecycle tests	1	203	0
Existing CI and self-contained ROS scope documentation	2	30	0

Offline manual acceptance from the configured checkout:

DIMOS_TRANSPORT=lcm LCM_DEFAULT_URL=memq:// uv run pytest --noconftest --import-mode=importlib -o addopts='' -q \
  dimos/protocol/pubsub/impl/test_cdr_ros_conversion.py dimos/core/test_transport_factory.py

71 source +71 isolated installed-wheel tests (including adjacent WebRTC cases), strict typing3 production files, applicable hooks and wheel pass; Nix unavailable. Wheel SHA256 042349862f65257240808500d14067ecc06320e78047590b3ce75ce71dc2bb0f.

The ROS runtime boundary is mocked with a separate typestore assembled from the complete schemas; tests exercise actual generated codecs and transport wrapper with pose/Image/Imu, big/little endian, source epoch+1ns, row padding, covariance, malformed header, schema/class mismatch, missing dependency, provider ownership and pickle identity. The fixture immediately restores rosbags.usertypes after creating its oracle so global generated class identities survive subsequent tests.

Actual ROS 2 node/discovery acceptance has not run: this environment lacks rclpy and compiled ROS message packages. Native DimOS artifacts do not require ROS; a ROS consumer additionally needs the matching ROS package built in its sourced workspace. Wire/schema compatibility is not a claim that DimOS builds ROS nodes. Existing user-story documentation now states this explicitly. No CI polling, benchmarks, hardware, host changes or ROS/system installation performed. Remaining whole-body/other graph closures, fixture regressions, Gate B cleanup and final ancestry organization remain open.