feat: [Remote rendering 3.5c] Server creates color lookup table and client stops creating its own

[LKasianAnsys]

Issue

Addresses #23

Context

This is the third 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.

Until now the browser created and configured its own lookup table (LUT) on every color apply. The server never set one explicitly; VTK created a default under the hood when the mapper was first serialized (unbuilt, component mode, default hue), and the client replaced it on every apply. Two issues arose from this: replacing a table the wasm object manager still indexed crashed the runtime (about 1 in 3 add_dataset calls after a part was colored), and the server could not say how a scene was colored without asking the browser.

This PR moves LUT ownership to the server. Each part's VTK pipeline creates a fixed magnitude table (blue-to-red hue) at construction and sets it on the mapper, so it ships with the mapper's serialized state; the client uses the table it receives and no longer callsCreateDefaultLookupTable, SetHueRange, or SetVectorModeToMagnitude. Component selection stays on the mapper (-1 for magnitude).

With the client no longer authoring color state, we are able to clean up the following pieces on the wire and save paths:

• min/max on the set_part_color_variable trigger. The server now applies its own record's range for the slot; the client was sending values the server now ignores.
• VisorSaveStateResponse._discard_browser_variable_states. The save_state API now takes variable_states from the server's records; this is no longer needed.
• IRenderer.refresh_color_variable_range and its two implementations: was initially added as a no-op stub in remote rendering user story 1.2 but was never wired up as originally expected. As of user story 3.5a, range changes go through apply_color_variable.

Copilot summary

In this pull request, the server now creates and manages the color lookup table for part coloring, and the client no longer creates or configures its own lookup tables. The payloads and APIs have been updated to remove the need for clients to send color range (min/max) values, and the server now applies its own authoritative range. Related code, tests, and documentation have been refactored to reflect this new responsibility split.

Server-side rendering and lookup table management:

• The server's VtkNodePipeline now owns and builds a vtkLookupTable for each part, which is set on the mapper and never reconfigured by the client. The lookup table is created with a blue-to-red hue range and magnitude mode, and is serialized with the part's state. [1] [2] [3] [4]
• The server's set_part_color_variable logic and related documentation have been updated: the color variable range is no longer carried in the payload, and the server uses its own record’s effective range. [1] [2]

Client-side changes:

• The client (WasmRenderer) no longer creates or configures lookup tables when setting color variables. The LUT-related calls are removed, and the payload sent to the server omits min/max fields. [1] [2]
• Tests for the client have been updated: they now verify that LUT configuration is not performed, and that payloads contain only the required fields. [1] [2] [3]

API and validation cleanup:

• The SetPartColorVariablePayload model and related test cases have been updated to remove min_val and max_val fields, and to ensure that payloads without these fields are properly handled. [1] [2] [3]
• Obsolete server-side methods for refreshing color variable ranges and legacy validation logic for discarding browser-side variable states have been removed, simplifying the codebase. [1] [2] [3] [4]

These changes centralize color mapping logic on the server, reduce client complexity, and clarify the contract between client and server for part coloring in VISOR.

[ansBAkula]

Discussed and tested.