fix(ui): Add debounce timeout when removing status bar loader (CODY-4706)

[sanjayesn]

CODY-4706

The status bar icon did not appear to spin during autocomplete generation. This PR adds a debounce timeout when removing status bar loaders to ensure that the loader spins for a minimum duration.

@valerybugakov also mentioned that the status bar icon does not spin when switching accounts, but I could not reproduce this issue.

Test plan

Added a simple unit test verifying loader mutations are properly tracked.

The following screen recording shows the status bar icon spinning both during autocomplete generation and account switching:

Screen.Recording.2025-01-30.at.1.40.25.PM.mov

[sanjayesn]

Is there a better way of reading a private property with no accessor method? Imagining we either add a getter in StatusBar.ts, do some type conversions, or test this a different way.

[jamesmcnamara]

This is a good question. Often times, we'll expose a method with the name blanketyblankForTesting to sidestep this issue. However usually the best practice is not get at the guts of the internals of the class at all, but just test its externally visible side effects because at the end of the day, it doesn't matter what the private values of a class are, only how it affects other code. So for example, mocking out the call to createStatusBar and testing that your change actually led to the status bar being set with a loading icon or whatever.

However, once you make the changes for autoedits, it may make more sense to write an E2E test for this.

[jamesmcnamara]

I personally don't think this is the best way to handle this issue. I bet someone told you this would be the easiest way to do this, and it is kinda harmless (who really cares about a 250ms loading indicator when things have already been loaded? who could even tell?) but I still think if we're gonna fix this, let's try to actually fix this.

Broadly, I see two issues that this ticket could be referring to:

1. The autocomplete provider does not show a loading indicator for a very long time when triggered.
   We can trace the code a bit and find that the loading signal is this helper method that is created by the InlineCompletionItemProvider and then passed and finally triggered here. So if the issue is that we aren't seeing the indicator for long enough then maybe we need to move that call earlier in the pipeline.

However, my suspicion is that this isn't the issue at all, and that the real issue is that we are never seeing a loading indicator on auto edits and not auto complete.

If we look at the AutoeditsProvider, we see it never calls the addLoader method during its predictions (it doesn't even have a reference to CodyStatusBar). So I suspect the real solution is to wire that util through to the auto edits provider and then wrap a loader call around the actual edits prediction. For that though, you may need to sync with @hitesh-1997 or @valerybugakov to determine the most appropriate time to trigger it (or maybe since it's low risk we can just wrap it around the getPrediction method and put the cleanup in a finally?)