[#1309] Demonstrate independent moving camera platforms

[suhaslord]

• Tickets addressed: Related to Add Dynamic Pose Update Interface to Camera Module via Message Subscription #1309; implements the moving-platform alternative suggested in the maintainer's issue comment. Does not close the requested camera pose-input API change.
• Review: By file
• Merge strategy: Merge (no squash)

Description

Add scenarioMovingCamera.py to demonstrate two independently commanded instrument-camera platforms on a spacecraft with a fixed prescribed attitude. Native rotation and translation profilers read command messages, including new commands at 15 seconds. Platform configuration messages supply inertial poses to vizInterface; each camera is attached to its own named platform.

The example uses massless kinematic platforms and zero platform center-of-mass offsets so the logged pose and camera parent-frame origin coincide. It demonstrates independent camera pose commands, not closed-loop target tracking, actuator dynamics, or a new input port on the image-corruption module. The camera documentation explains how to use the existing platform subscriptions with cameraConfigOutMsg. No native implementation or public API changes.

Verification

• Six new tests passed, covering both maneuver stages, nonidentity host and mount frames, independent boresight changes, fixed host pose, optional visualization disabled, and native camera-parent/pose buffers.
• Targeted new and existing rotation/translation tests: 70 passed in 1.73 s, no skips.
• Applicable repository pre-commit hooks, Python compilation and whitespace checks passed.
• Focused Sphinx build of the example and new documentation passed with warnings treated as errors. This is not the full repository documentation build.

Local validation used macOS arm64, Python 3.12, NumPy 2.3.5 and the official Basilisk 2.12.0 native wheel. A wider vizInterface regression collection could not run because that wheel lacks the generated Basilisk.utilities.vizProtobuffer.vizMessage_pb2 decoder. New tests validate actual native visualization buffers without that decoder. Rendering in Vizard, a native build of current develop, the full project suite and upstream CI remain unverified; this PR stays draft pending review and that validation.

Documentation

Adds the example to examples/_default.rst, a moving-platform section to the camera module guide, an honest workaround entry in known issues, and a release-note snippet. The example explains frame conventions, task ordering, massless-platform limitations and optional Vizard replay export.

Future work

Confirm rendered camera views in Vizard and the maintainer's preferred resolution of #1309 before closing the issue. Closed-loop target tracking and physical actuator dynamics remain separate work.