feat: Remote rendering 3.1c - register per-part triggers, serialize VTK access with lock, trigger payload validation

[LKasianAnsys]

Issue

Addresses #18

Context

This is the 3rd 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 third step: exposing the server-side apply methods as Trame triggers, plus a lock on the VTK operations from the scene coordinator layer. These triggers still have no callers in this PR. The client-initiated triggers are added in PR 4, and this is extended to save/load state in PR 5.

Notes

• A re-entrant lock was added on VisorSceneBase, taken by all ten public entry points there that touch VTK. This is the entrypoint into the VTK graph from the outside, so one lock there is comprehensive. It is scoped to this story: it serializes access only, and is not a general threading fix.
• No wasm flush was added on the trigger path. Each coordinator method writes the registry record and applies it to VTK, and pushes nothing to the client. (Adding pushes back to the client is deferred to Phase 6 of the remote rendering epic, where the round trip mechanism will be designed and implemented.)
• Trigger boundary: The call into the scene is typed by a ScenePartStateApi Protocol, declared in the app module so nothing imports a scene type. This is a type only, no runtime behaviour.
• Trigger validation: Payloads are parsed into Pydantic models. A malformed payload is rejected before anything reaches the registry or VTK.

Copilot Summary

This pull request introduces a new set of per-part rendering triggers for VISOR (3.1c), ensures robust payload validation for these triggers, and adds a thread-safe locking mechanism to serialize all VTK access in the scene. These changes increase the reliability and maintainability of the rendering workflow, especially in multi-threaded environments. The most important changes are grouped below:

Per-part trigger registration and API:

• Added a structural protocol ScenePartStateApi and corresponding payload models for each per-part trigger in local_app.py, enabling type-checked, modular, and validated per-part state updates from the frontend [1] [2].
• Registered new per-part triggers in LocalApp (set_part_visibility, set_part_opacity, set_part_diffuse_color, set_part_selected, set_part_color_variable, clear_part_color_variable) and delegated their handling to the injected scene API, with robust payload validation using Pydantic models [1] [2].
• Injected the scene as the per-part state API into LocalApp during initialization, ensuring the triggers are routed correctly [1] [2] [3].

Thread safety and VTK access serialization:

• Introduced a re-entrant lock (_vtk_lock) in the scene base class to serialize all server-side VTK mutations and rendering operations, preventing race conditions between the trame event loop and main thread [1] [2].
• Wrapped all VTK-mutating methods (apply_state, clear, populate_scene, finalize_scene, update_widgets, add_dataset, remove_dataset, update_variables_for_dataset, render, reset_camera) with _vtk_lock to ensure thread-safe access [1] [2] [3] [4] [5] [6] [7] [8].

The base branch was changed.