feat: Remote rendering 3.1e - source per-part state from registry on save and restore it on load

[LKasianAnsys]

Issue

Resolves #18

Context

This is the last 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 last step: sourcing the per-part state from the server-side registry during the save_state API, and restoring it on load_state.

• save_state: Currently, the get_state method on VisorSceneBase sources the per-part state from the client's getAppStateAsync response. This PR instead sources it from runtime_state_dict, as it now is considered the source of truth on the per-part viewer state.
• load_state: When a state is loaded, this PR now loads the per-part state into the dataset registry on the server, and applies every part to the server's pipeline, before the scene description is built.
  • No wasm flush is added here, the current load_state mechanism is still used for pushing the state to the server. This will be addressed in Phase 6 when adding round trips to the system (as we keep a client-side apply until then, which races a
• Schema change: because the server now needs to apply the color properties on its pipeline on a load_state, adding three fields it needs: array_name, type, num_components.
  • PersistedViewerState version kept at 1.0, Backwards-compatibility with existing persisted state is maintained by parsing the variable ID, which is presently a hash of those values, separated by ::.
  • The runtime VisorSceneDetails schema version does not need a bump because the new fields don't affect it.

---

Copilot summary

This pull request implements robust support for per-part state persistence and restoration in VISOR (3.1e), ensuring that all necessary variable identity fields are sourced from the registry during save and correctly restored on load. It introduces logic to derive missing variable identity fields for backward compatibility, updates both backend and frontend models to explicitly carry these fields, and enhances the server's logic for restoring per-part visualization state.

Persistence and restoration of per-part state:

• The backend (VisorSceneBase) now sources per-part state from the registry during save, ensuring that the most up-to-date runtime state is persisted. On load, it restores all per-part properties (visibility, color, variable mapping, etc.) to the VTK pipeline, with robust error handling and logging for mismatches or missing data. [1] [2]

Variable identity field handling and backward compatibility:

• The PersistedSceneState model now includes logic to derive missing variable identity fields (array_name, type, num_components) from the variable identifier, enabling backward compatibility with older save files. This is done via a validator and a helper function that parses the identifier format. [1] [2]

Explicit variable identity fields in models:

• The VisorVariableState backend model and the corresponding frontend VisorSpectrumState now explicitly carry array_name, type, and num_components fields, and ensure they are serialized and deserialized correctly. This eliminates the need for consumers to parse the identifier string to access these properties. [1] [2] [3] [4] [5]

Clarifications and comments:

• Improved documentation and comments throughout the codebase to clarify the purpose of new logic, the scope of locks, and the rationale for certain design choices (e.g., error handling, lock granularity, and compatibility boundaries). [1] [2]

These changes collectively ensure robust, future-proof persistence and restoration of per-part visualization state, with explicit variable identity tracking and strong backward compatibility.

The base branch was changed.