Replace dotnet run with dotnet exec to bypass SDK argument parsing regression

dotnet run in SDK 10.0.300 incorrectly forwards its own options
(--verbosity, --configuration, --no-build) as application arguments
on the CI agent (Ubuntu 22.04). This cannot be reproduced locally
with the same SDK version but manifests consistently on hosted agents.

Since we build separately anyway (--no-build), switch to dotnet exec
which directly invokes the built DLL without any argument parsing
ambiguity.

Author: paulmedynski

eng/pipelines/stress/stress-tests-job.yml

@@ -185,6 +185,11 @@ jobs:
 
       # Run the stress tests for each .NET runtime.
       #
+      # We use `dotnet exec` instead of `dotnet run` because SDK 10.0.300 has a regression where
+      # `dotnet run` forwards its own options (--verbosity, --configuration, --no-build) as
+      # application arguments on hosted Ubuntu agents.  Since we build separately above, `dotnet
+      # exec` is both simpler and immune to argument-parsing changes in the SDK.
+      #
       # The condition and continueOnError work together to achieve the following behavior:
       #
       #   condition: and(succeededOrFailed(), eq(variables['buildSucceeded'], 'true'))