Wait for the resolved dependencies, not for the application to go idle

Load_Dependencies_Resolves_References_And_Keeps_Them_In_The_List timed out on a loaded
CI agent. The idle predicate it waited on also covers the dispatcher queue, and
LoadDependenciesAsync ends with RefreshDecompiledView, so the test was waiting for a
decompilation to finish - work whose duration is a property of the machine, not of the
condition being asserted. Instrumenting the wait shows every assembly already loaded on
the first poll while dispatcher jobs stay queued for seconds, so the loads were never the
holdup.

Waiting for the list to show the resolved dependencies drops the dependency on machine
speed: under a deliberately shortened one-second deadline the previous wait failed every
run and this one passed every run.

Assisted-by: Claude:claude-opus-5:Claude Code

ILSpy.Tests/AssemblyList/AssemblyTreeTests.cs

@@ -1791,7 +1791,14 @@ public class AssemblyTreeTests
 
 		// Act -- run Load Dependencies on the System.Net.Http node.
 		await vm.AssemblyTreeModel.LoadDependenciesAsync(new SharpTreeNode[] { httpNode });
-		await Waiters.WaitForIdleAsync();
+		// Wait for the resolved dependencies to show up in the list, not for the application to go
+		// idle. The command ends with RefreshDecompiledView, so waiting for the dispatcher queue to
+		// drain means waiting for a decompilation whose duration is a property of the machine; on a
+		// loaded agent that outlasts the idle deadline. What this test asserts - and the refresh
+		// regression it guards against - is visible in the assembly list itself.
+		await Waiters.WaitForAsync(
+			() => vm.AssemblyTreeModel.AssemblyList!.GetAssemblies().Any(a => !before.Contains(a.FileName)),
+			description: "the resolved dependencies to appear in the assembly list");
 
 		// Assert -- references were resolved AND survive in the list as auto-loaded entries.
 		var added = vm.AssemblyTreeModel.AssemblyList!.GetAssemblies()