[Feature] Implement granular state synchronization API for real-time editing

[davidbits]

Related Package / Scope

Core Simulator (fers)
Desktop UI (fers-ui)

Is your feature request related to a problem? Please describe.

The current architecture for synchronizing the UI state (Zustand) with the C++ simulation backend relies on a "Full State Replacement" strategy. Whenever the scenario changes, the frontend serializes the entire world to JSON, and the backend (json_to_world) clears the existing World object and rebuilds it from scratch.

While robust for consistency, this approach is computationally expensive ($O(N)$ relative to scenario complexity). It creates a bottleneck that prevents real-time feedback. For example, dragging a slider to change a transmitter's frequency or moving a platform waypoint cannot instantly update the 3D preview (RF links, antenna patterns) without freezing the UI or requiring a heavy debounce delay.

Describe the solution you'd like

I would like to transition from full-world replacement to Granular State Synchronization. This involves extending the C-API to allow mutating specific properties of existing simulation objects by their ID, without destroying and recreating the entire world context.

Key Implementation Steps:

1. C++ Core (libfers):

   • Extend api.h and World to support lookup-by-ID.
   • Implement specific setter functions, for example:
     • fers_update_platform_motion(context, id, waypoints)
     • fers_set_component_property(context, id, property_enum, value)
     • fers_set_antenna_orientation(context, id, orientation)

2. Rust FFI (fers-ui/src-tauri):

   • Bind the new C-API functions.
   • Expose fine-grained Tauri commands (e.g., update_platform_position, update_transmitter_params).

3. Frontend (fers-ui):

   • Refactor the ScenarioStore actions (updateItem) to invoke these specific Tauri commands immediately alongside the local state update.
   • Retain the full JSON sync only for initial loading or complex topology changes (e.g., adding/removing components).

Describe alternatives you've considered

• Debounced Full Sync (Current Implementation): We currently debounce the syncBackend() call. While this prevents the UI from freezing during typing/dragging, it introduces perceptible latency. The visualizer (RF links, etc.) is always slightly behind the user's input.
• Dirty Checking: Only syncing when the visualizer requests data. This reduces CPU usage when idle but causes massive stutter frames when the visualizer eventually requests the data during an interaction.

Additional Context

This architecture shift is necessary to support planned high-performance features, such as:

• Real-time "scrubbing" of the timeline with live RF link updates.
• Interactive 3D gizmos for moving platforms directly in the WorldView.
• Live tuning of antenna parameters during active visualization.