feat: Remote rendering 3.1d - route client per-part mutations through the server triggers

[LKasianAnsys]

Issue

Addresses #18

Context

This is the 4th of 5 PRs for user story 3.1 (#18) of the phased implementation plan (here) for adding remote rendering in VISOR.

Per-part visual state (visibility, opacity, diffuse color, color variable), is currently held client-side on VisorPartState and reaches the server only via getAppStateAsync when the save_state API is called. This story inverts that, making VisorDatasetRegistry the source of truth for per-part state by the end of 3.1.

This PR is the fourth step: adding client-initiated calls to the server-side Trame triggers that apply per-part mutations to the registry and to VTK. This is the PR where the client and server halves are wired together: per-part changes made on the client are sent to the server and applied there. This results in a behaviour change: per-part changes made in the browser now survive a refresh rather than resetting to defaults.

Notes

• The client still applies locally as well as calling the trigger. Nothing pushes back from the server on this path yet (this is the round trip work deferred to Phase 6 of the remote rendering epic), so a client that stopped applying would leave the interaction with nothing rendering it.
• Rendering behaviour is otherwise unchanged. The client still applies every change itself, so what is visible in the viewer is the client's own apply, not the server's. The one thing that is evidence about the server is the refresh: per-part state surviving it means the triggers wrote to the registry.
• The client-side guards that skip the call when the value is unchanged are kept.

Regression Test Update

Because this PR results in a viewer behaviour change, a regression test update is required. Any per-part changes within a viewer session now survive a refresh or new connection, and we had a test that relied on a shared fixture resetting to defaults on a new connection; this need updating.

The TestTensorComponentColoring.test_initial_render_baseline test now results in a e2e02_tensor_initial_render_current_<date>.png that does not match baseline in the failed regression test run. The fixture is used across tests, and the test checks the initial state of the viewer, which used to revert to the default color-by per-part property, but the server now stores the previously-applied value and it survives a refresh/new connection.

Made two changes:

• Moved TestTensorComponentColoring before TestTensorVariableDropdown in test_variable_components.py, to allow e2e02_tensor_initial_render to run before other operations.
• Changed the order of the components_to_test from ["Magnitude", "XX", "YY", "ZZ"] to ["XX", "YY", "ZZ", "Magnitude"] to keep the image as expected in e2e01_tensor_component_dropdown. (This was getting set to "ZZ" because the server remembered the last setting from the previous test).

---

Copilot summary

This pull request implements remote per-part mutation support in the rendering pipeline, ensuring that all per-part user actions (such as visibility, opacity, color, and selection changes) are now sent to the server via triggers in addition to being applied locally. The changes introduce a new trigger sender interface, update the renderer implementations to support these triggers, and add comprehensive tests to verify that both local and remote mutations occur as intended.

The most important changes are:

Remote per-part mutation infrastructure:

• Added a TrameTriggerSender type to IRenderer.ts to abstract the transport for sending per-part mutations to the server, and updated the IRenderer interface with six new sendPart*Async methods for visibility, opacity, color, selection, and variable coloring triggers. [1] [2]
• Updated WasmRenderer to accept an optional trigger sender, and implemented all six sendPart*Async methods to call the appropriate server triggers using the injected sender. Failures are logged but do not affect client-side behavior. [1] [2] [3] [4]
• Modified NullRenderer to provide no-op implementations for the new server trigger methods, ensuring compatibility in environments without a server backend.

Scene graph and application integration:

• Updated the scene graph logic to ensure that all per-part mutations (e.g., color resets, color changes) invoke the corresponding sendPart*Async methods, guaranteeing that server state stays in sync with client actions. [1] [2]
• Modified the application entry point to inject the trigger sender into the renderer when constructing it, enabling the remote mutation path.

Testing and validation:

• Added a comprehensive test suite (VisorSceneGraphPartTriggers.test.tsx) that verifies every per-part user action results in both a local renderer mutation and the correct server trigger being sent. Tests also cover group-node fan-out and ensure that no triggers are sent for group nodes themselves.

These changes collectively ensure that all relevant client-side mutations are reliably mirrored to the server, supporting consistent collaborative or remote rendering workflows.

[LKasianAnsys]

@AnSergioFern Adding you to make sure the regression test update looks OK to you. I included a section on the regression test in the description - let me know if you have feedback/suggestions.

The base branch was changed.

[LKasianAnsys]

@margalva thank you for the approval. It needs a reapproval after 3.1c was merged into main.