[tenzinplatter]

Turns on zenoh shared memory in the session and router configs, with a 512 KiB pool per process, and requires rmw_zenoh_cpp >= 0.6.9.

Why 512 KiB

zenoh pins (mlocks) every SHM pool it creates, and every peer pool it receives from. With the 48 MiB default, gama + missim locked about 2.6 GB. A census of the combined graph under a missim scenario showed about 42 KiB/s in total, with the largest message about 10 KiB. A 512 KiB pool, the same size as the FastDDS default segment, leaves about 50× headroom. Locked memory drops to about 100 MiB.

Why rmw_zenoh >= 0.6.9

• 0.6.6 ignores transport_optimization.pool_size and always creates its pool at rmw_init, sized only from ZENOH_SHM_ALLOC_SIZE. Under a low memlock limit, every node dies with Failed to create POSIX SHM provider.
• 0.6.9 sizes the session's lazy provider from pool_size. If the pool can't be created, it logs one ERROR and falls back to the network.

Consumers must set memlock: -1

• Containers need ulimits: memlock: -1. Docker's default is 8 MiB.
• Receive-side mlock failures silently drop messages, logged only at DEBUG (SHM attach/mlock failure silently drops received sample and leaves partial metadata state eclipse-zenoh/zenoh#2788). Don't use a tight finite limit.

Tested with gama and missim on the dev channel: every node started, with no SHM errors and about 100 MiB locked. pixi run test: 125 passed.

Declared run deps for spawned tools

launch_ext starts rmw_zenohd (rmw_zenoh_cpp), fast-discovery-server and fastdds shm clean (fastdds), and ros2 daemon stop (ros2cli). None of these were declared before. Now all three are listed in pixi.toml and package.xml. Only pixi.toml sets a version (rmw_zenoh_cpp >= 0.6.9).