--navigateto skips the saved-path restore

When --navigateto (-n) is supplied on the command line the user is
asking us to navigate to a specific entity. Today's code restores the
previously-saved tree path AND then runs the explicit target, which
produces two concurrent decompiles racing on SelectedItem (last write
wins). The saved decompile contaminates perf measurements taken via
`-n T:Some.Type` and adds GC pressure to startup for no user benefit.

Assisted-by: Claude:claude-opus-4-7:Claude Code

ILSpy/AssemblyTree/AssemblyTreeModel.cs

@@ -301,6 +301,14 @@ namespace ILSpy.AssemblyTree
 			// crosses an AssemblyTreeNode whose EnsureLazyChildren synchronously blocks on
 			// GetLoadResultAsync — by going async here and awaiting the load, we let the
 			// initial paint happen first and the UI stays responsive while metadata loads.
+			//
+			// Skipped when --navigateto was supplied on the command line: the user explicitly
+			// asked us to navigate somewhere else, and racing the saved-path restore against
+			// the explicit target produces two concurrent decompiles (the saved one then the
+			// requested one — last write wins on SelectedItem). For perf-benchmarking via
+			// `-n T:Some.Type` this matters: the saved decompile pollutes the measurement.
+			if (App.CommandLineArguments?.NavigateTo is { Length: > 0 })
+				return;
 			var savedPath = settingsService.SessionSettings.ActiveTreeViewPath;
 			if (savedPath is { Length: > 0 })
 				_ = RestoreSelectedPathAsync(savedPath);