Fix memory leak in automation demo visualization loop

[Copilot]

RAM grows continuously during automation demo due to allocations in the visualization update loop (runs at ~100Hz) and demo loop state retrievals.

Changes

Visualization loop (primary fix)

• Reuse single List<> instance instead of allocating new one every 10ms (~100/sec reduction)
• Replace LINQ Where() with indexed for-loop to eliminate enumerator allocations
• Fix bug: change early return to continue to process all manipulators
• Throttle position requests: Reduce network polling from 100 Hz to 10 Hz to minimize immutable state object creation
• Cache positions: Store last known position per manipulator to avoid redundant network calls

Demo loop

• Cache coordinates at loop start; reduce GetState<SceneState> calls from 5 to 1 per iteration (80% reduction)
• Extract CheckDemoStillRunning() helper to deduplicate state checks

State change handler

• Replace foreach with for-loop in OnSceneStateChanged()

Position request throttling

• Implement 100ms throttle window per manipulator (10 Hz vs 100 Hz)
• Cache last known positions and timestamps
• Reduces network requests by 90% and immutable state allocations by 90%
• Clear caches on disconnect to avoid stale data

Example

Before:

private async Task UpdateVisualizationProbePosition(SceneState sceneState)
{
    List<(...)> requests = new();  // New allocation every 10ms
    foreach (var manipulatorState in sceneState.Manipulators.Where(...))  // LINQ allocations
    {
        if (error) return;  // Bug: exits early, skips other manipulators
        
        // Network request every 10ms per manipulator
        var positionResponse = await GetPosition(manipulatorState.Id);
        
        // Creates new immutable state object every 10ms
        _storeService.Store.Dispatch(...);
    }
}

After:

private async Task UpdateVisualizationProbePosition(SceneState sceneState)
{
    _visualizationUpdateRequests.Clear();  // Reuse existing list
    var currentTime = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();
    
    foreach (var manipulatorState in sceneState.Manipulators)  // No LINQ
    {
        if (error) continue;  // Process all manipulators
        
        // Throttle to 10 Hz - use cached position 90% of the time
        if (ShouldRequestPosition(manipulatorState.Id, currentTime))
        {
            currentPosition = await GetPosition(manipulatorState.Id);
            CachePosition(manipulatorState.Id, currentPosition, currentTime);
        }
        else
        {
            currentPosition = GetCachedPosition(manipulatorState.Id);
        }
        
        // Dispatch only when position actually changed (90% reduction)
    }
}

• Fixes Memory leak during automation demo #846

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Memory leak during automation demo</issue_title>
<issue_description>RAM usage grows continuously during the automation demo. Check for memory leaks in ephys link service for leaks in the demo loop implementation and also how manipulators update and check their position. The demo is also part of the manipulator inspector view model.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Memory leak during automation demo #846

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[kjy5]

@copilot The changes helped, but there is still a leak. Particularly when connected to manipulators. The memory grows more slowly now, but it still grows and needs garbage collection. I think this is due to the immutable state change system that the state system uses. Frequent updates to that are harsh. What suggestions are there to fix this?

[Copilot]

@copilot The changes helped, but there is still a leak. Particularly when connected to manipulators. The memory grows more slowly now, but it still grows and needs garbage collection. I think this is ...

I've addressed the remaining leak caused by the immutable state system. The issue was that we were polling manipulator positions every 10ms (~100 Hz), which created:

1. Network requests at 100 Hz generating async state machines
2. State dispatches at 100 Hz creating new immutable state objects

Solution implemented (commit 8340aa5):

• Added position request throttling (100ms interval = 10 Hz instead of 100 Hz)
• Cached last known positions per manipulator
• Reuse cached positions between throttle windows
• Clear caches on disconnect to avoid stale data

This reduces network requests and state allocations by 90%, from ~100/sec to ~10/sec. The visualization loop still runs at 100 Hz for smooth UI updates, but only fetches new positions and dispatches state updates at 10 Hz.

The GC should now be able to keep up with the reduced allocation rate.

[kjy5]

Superceded by #849