feat: [Remote rendering 3.5a] move variable ownership to server

[LKasianAnsys]

Issue

Addresses #23

Context

This is the first PR for user story 3.5 in Phase 3 of the remote rendering epic, which sees the visualizer state authority move from client to server.

In this PR, the server now defines the variables in a scene (name, type (POINT/CELL), # components, which parts carry it, and the magnitude and per-component ranges) and delivers them to the client on the scene details push. Custom ranges live on the server record and are set through a new set_variable_range trigger. The client in this PR is unchanged and still builds its own list (and doesn't use the new trigger yet); it switches over in the PR for 3.5b (#153).

Callouts:

• Every server-side mapper write on the color and range path re-serializes the mapper's VTK state inside the lock, so the next push to the client carries the current range. This is done in VisorLocalRenderer._serialize_part_state().
• Ranges are always-present fields on the record. There is no optional range and no client-side fallback; the client is meant to require delivered values.
• Persisted state file keys are unchanged.
• Until PR 3.5b (#153), a custom variable range edit in the UI stays client-side only. It is not sent to the server, and not persisted across a reload or in a save_state (those fall back to the default ranges as of this PR). This PR should be landed with 3.5b immediately after, which wires up the set_variable_range trigger and sees the ranges sent back to the server.

Sanity checks:

• run add_dataset and then remove_dataset after starting VISOR with a dataset loaded. Check that the part colors are as expected.
• save_state and load_state save from and load into the server's records

Copilot summary

This pull request introduces server-side ownership of variable ranges for VISOR. The main change is that the backend now maintains and manages variable ranges, rather than having the frontend provide them for each operation. This improves consistency and centralizes control. The update includes a new model for variable records, an API for setting variable ranges, and changes to payload handling and persistence.

Key changes:

Server-side variable ownership and management:

• Added VisorVariableRecord and VisorVariableRecords in visor_variable_record.py to represent and manage variable range state on the server, including logic for merging ranges and tracking per-variable metadata.
• Updated VisorVariableState to clarify that it is now a persisted projection of the server-owned VisorVariableRecord, not a passthrough from the client.

API and trigger updates:

• Introduced a new set_variable_range trigger and corresponding SetVariableRangePayload model, enabling the frontend to request range changes for variables, which are then applied scene-wide by the backend. [1] [2]
• Modified the set_part_color_variable trigger to ignore the min and max values from the payload, instead always using the server's effective range for the referenced variable slot. [1] [2]

Persistence and state handling:

• Changed the persisted viewer state (PersistedViewerStateV1.from_components) to require explicit variable state input, reflecting the server's ownership of variable ranges. [1] [2] [3]

Documentation and examples:

• Added new example assets for a VTK scene and its state, demonstrating the updated variable range handling. [1] [2]

[ansBAkula]

@LKasianAnsys Cool stuff. I tested it and it seems to work as described.

However, the description mentions that "every mapper write on the color and range path re-serializes." From what I can see, this is true for the mapper state itself: any UI changes related to the active variable on a VTK actor stay in sync and are correctly saved and restored when reloading the scene.

That said, the ranges do not appear to stay in sync. Changes to the range seem not to be serialized/restored in the same way as the active variable selection.

Is this expected behavior, or am I misunderstanding what the description is referring to?

[LKasianAnsys]

Hey @ansBAkula thank you for testing! What you saw is expected for this PR on its own. The range editor in the UI still only changes the client actors and does not call the new set_variable_range trigger yet, and the server ignores the min/max on set_part_color_variable. So the server record keeps the default range, and save/load restores that. The active variable persists because set_part_color_variable writes the server record.

The client starts sending set_variable_range in #153 (3.5b), and from there a range edit is stored on the sever, saved and restored. On main the save reply carried the range, so 3.5a alone is a temporary regression for custom ranges; it should land with 3.5b immediately after.

The "re-serialize" callout was about the serialized VTK state that trame-vtklocal serves to the client, not save/load. I'll reword that line in the description and will include a callout about the expected range behaviour until 3.5b