Multi-gripper support

Problem

Obstacle registration is fragmented across multiple paths in the manipulation stack:

• manual add/remove RPCs;
• floor setup during module initialization;
• collision-object input;
• Detection3D input;
• ObjectDB-driven object refresh and removal.

These paths do not share one clearly defined lifecycle owner. Some mutate the planning world through WorldMonitor, while others are handled through WorldObstacleMonitor. Source identity, update behavior, removal behavior, and the relationship to the active planning-world obstacle state are therefore distributed across separate code paths.

This makes it unclear which component owns the authoritative registration state and prevents downstream consumers from relying on one consistent obstacle-registration lifecycle.

Impact

Any consumer that needs the accepted obstacle state must understand or compensate for multiple registration routes. Changes to obstacle handling risk covering only a subset of additions, updates, or removals.

Synced from DIM-1310 by che

Start by tracing the manual RPCs, module initialization, collision-object input, Detection3D input, and ObjectDB refresh/removal paths through WorldMonitor and WorldObstacleMonitor. Define which component owns authoritative obstacle registration, then verify that source identity, updates, removals, and active planning-world state follow one consistent lifecycle.