Surface pose validity (GRIP_IS_VALID) in deviceio / provide a stock PoseGate node for occlusion snap-back

[johnnynunez]

Context

When XR controllers leave the headset's camera view, the OpenXR runtime keeps streaming an IMU-extrapolated pose and is_tracking remains true. On re-acquisition the pose teleports. Downstream, the robot lurches toward the ghost target.

Evidence

• Measured lurches of up to 73 cm/frame on controller re-acquisition (Quest 3 via CloudXR, SO-101 follower).
• We implemented a PoseGate at the example layer consuming the runtime's GRIP_IS_VALID flag; verified via synthetic replay: 73.2 → 0.2 cm/frame.
• A rate limiter alone is the wrong tool here: it converts the teleport into a fast-but-legal slew toward a bogus target instead of rejecting it (this motivated the anomaly-rejection tier in PR Add optional rate-limiting retargeters for bare position-servo followers (SO-101 class) #727).

Proposal

Either (in order of preference):

1. Surface pose validity as a first-class deviceio output (GRIP_IS_VALID and friends), so any retargeting graph can gate on it, and/or
2. Ship a stock PoseGate retargeter node that holds the last valid pose (and optionally signals the clutch to disengage) while validity is false.

This affects every XR consumer of the library, not just our integration — occlusion is routine in tabletop teleop (the operator's own body blocks the cameras constantly).

Happy to upstream our PoseGate implementation if the design is agreeable.

---

Part of the field-integration feedback series (SO-101 + reBot DevArm, June 29 – July 6). Priority suggestion: P0.