feat: [Remote rendering 3.3d] sync camera to server on orientation widget

[LKasianAnsys]

Issue

Resolves #21

Context

This is the last PR of 4 to move ownership of widget state from the client to the server.

Camera sync-back reports the settled browser camera to the server through the sync_camera trigger, and the server drops any report whose origin is not gesture. CameraGestureTracker sets that origin: a camera change counts as a user input only when it follows a mouse drag, a wheel event, or a z / r keydown. Everything else is programmatic, which is what stops a server-pushed camera from echoing back.

Problem: clicking an orientation cube face moved the camera, but the report arrived as programmatic and was dropped. The widget animates the camera after the release, outside the input the tracker watched.

Change:

• A mouseup on the canvas opens the same 300ms input window as a wheel event or a z/r keydown.
• Client-side only; the report still goes through sync_camera.

Preferred approach, after a VTK upgrade

The approach in this PR was written after a first approach was tested and introduced a regression, due to a known upstream issue that has been fixed in a newer version of VTK.

The initial implementation observed the widget's EndInteractionEvent in the WasmRenderer constructor and marked the gesture from there, which is the more precise signal: it fires once per widget interaction and makes no timing assumption.

However, setting up the observer requires calling getVtkObject, which breaks add_dataset on VTK 9.6.1. Proxying the widget makes the client allocate ids that collide with the next dataset's, so the new dataset does not render until a reload.

This is the same bug as an existing TODO in VisorFrontend.tsx, which was previously reported as an issue to Kitware. The bug has a fix, and a test of VTK 9.7.0 confirms it resolves the issue encountered here. Once we upgrade to 9.7.0, we can restore the observer implementation. If the VTK bump lands first, we can revert it here; otherwise if the workaround lands first, a comment in the WasmRenderer constructor includes what to restore.

Kitware issue: #86
Upstream fix: VTK MR

---

Copilot summary

This pull request adds support for correctly attributing camera movements made via the orientation widget as user gestures, ensuring these interactions are properly recognized and synchronized with the server. This addresses a gap where orientation widget actions were previously classified as programmatic, causing them to be ignored by the server. The implementation includes new methods, updated event observers, and expanded test coverage to verify the behavior.

Orientation widget gesture attribution:

• Added a new method noteWidgetGesture to CameraGestureTracker that marks orientation widget interactions as user gestures, using the same logic as DOM-based gestures to ensure correct attribution even if the event order varies.
• Exposed noteWidgetGesture in VtkScene to allow WasmRenderer to mark gestures on behalf of the orientation widget, since the underlying tracker is private.
• Updated WasmRenderer to observe the orientation widget's EndInteractionEvent and call noteWidgetGesture, ensuring camera moves initiated by the widget are marked as user gestures.
• Added documentation explaining the need for explicit gesture marking for orientation widget actions.

Test enhancements:

• Expanded test doubles and renderer setup in WasmRendererWidgetTriggers.test.tsx to support orientation widget gesture tracking and validation. [1] [2] [3]
• Added new tests in both CameraGestureTracker.test.js and WasmRendererWidgetTriggers.test.tsx to verify that orientation widget interactions are correctly observed and attributed as gestures. [1] [2]