chore: [Remote rendering 3.6c] Reserialize actor state inside the renderer apply methods

[LKasianAnsys]

Issue

Addresses #24

Context

Until now, the server reported an object's version from the live VTK object, but served its content from a cache that only a full update refreshed. Five per-part writes (visibility, opacity, diffuse color, selection, global edges) changed the object without refreshing the cache, so the next client fetch (a refresh, or the next update) got a new version with the old content and applied the pre-write value. The color-variable path did not have this problem because it already refreshed the cache inside the renderer; this PR makes every write do the same.

This went unnoticed because on refresh, the client re-applied the server's record over whatever it fetched. PR #166 removes that reapply, which is why this PR needs to land first.

Changes

• Each VisorLocalRenderer apply method re-serializes the object it wrote as its last statement, through one helper.
• The camera and plane re-serializes move inside the renderer the same way; serialize_camera_state and serialize_cross_section_state are removed from IRenderer. The interface states the precondition: on return, the state this renderer serves reflects the write, and the client is not notified.

Manual check

1. Load one dataset; set a part's opacity to 30
2. Run add_dataset from Python; the rebuild should show the part at 30 opacity.
3. Set the part's opacity back to 100; reload the browser.

Before: panel is at 100, but the part is translucent. The cache still holds 0.3 from the add_dataset serialiation, and the client only re-applies a value that differs from its default, so 100 is never written over it.
After: the panel is 100, and the part is opaque (ie it reflects the 100 opacity as expected)

Copilot summary

This pull request improves the remote rendering system by ensuring that the renderer's internal state is always kept in sync with client-facing state after any mutating operation. It does this by reserializing the relevant VTK object(s) inside each renderer "apply" method, so the state served to the client always reflects the latest changes. The PR also removes now-unnecessary explicit serialization methods and updates documentation to clarify these behaviors.

Renderer State Synchronization Improvements

• All mutating methods in IRenderer (apply_visibility, apply_opacity, apply_diffuse_color, apply_selected, reset_camera, sync_camera, set_projection, set_edges_visible, sync_cross_section_plane) now guarantee that, on return, the state served to the client reflects the write, and the client is not notified. Docstrings have been updated to document this contract. [1] [2] [3] [4] [5] [6] [7]

• In VisorLocalRenderer, each mutating method now calls a new _serialize_vtk_object, _serialize_camera_state, or _serialize_cross_section_state helper as appropriate, immediately after making changes, to update the serialization cache. This ensures the client-facing state is always current. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]

Codebase Simplification

• Removed the now-unnecessary serialize_camera_state and serialize_cross_section_state methods from the interface and implementation, as serialization is now handled automatically after every write. [1] [2] [3] [4]

Documentation and Maintenance

• Added and updated docstrings throughout the renderer code to clarify the new synchronization contract and the lack of client notification after state changes. [1] [2] [3] [4] [5] [6] [7]

Internal Refactoring

• Introduced a reusable _serialize_vtk_object helper in VisorLocalRenderer to centralize and standardize VTK object reserialization logic.