`dotnet run --launch-profile` ignores `workingDirectory` from launchSettings.json

### Describe the bug

`dotnet run --launch-profile ` reads the profile and applies `commandLineArgs` and `environmentVariables`, etc..., but ignores `workingDirectory`. The process always starts in the project directory. No warning or diagnostic is emitted either.

The other keys from the same profile are applied correctly, but `workingDirectory` is not supported. This makes `launchSettings.json` IDE specific (which is annoying if you dont use any IDE)

Both Visual Studio and Rider both follow the `workingDirectory` property. For anyone using .NET from an editor that shells out to `dotnet run` (Neovim, Helix, or any other DAP-based setup), there is no way to express a per-profile working directory at all.

This was previously reported in #20885 (2021), which was closed as stale on 2026-05-07 and mislabeled as `Area-WebSDK`, but the behavior is not web-specific. See also #9949.

### Steps to reproduce

```bash
# Make new console project
dotnet new console -o demo
cd demo

# Create rundir and Properties folder
mkdir -p Properties rundir

# Dummy program
cat > Program.cs <<'EOF'
Console.WriteLine("CWD = " + Environment.CurrentDirectory);
Console.WriteLine("ARGS = [" + string.Join(' ', args) + "]");
Console.WriteLine("FOO = " + (Environment.GetEnvironmentVariable("FOO") ?? ""));
EOF

# Example launchSettings
cat > Properties/launchSettings.json <<'EOF'
{
"profiles": {
"Test": {
"commandName": "Project",
"commandLineArgs": "--nc",
"workingDirectory": "rundir",
"environmentVariables": { "FOO": "bar" }
}
}
}
EOF

# Run.
dotnet run --launch-profile Test
```

### Expected behavior

The `workingDirectory` property should be respected.

```
CWD = /path/to/repro/rundir
ARGS = [--nc]
FOO = bar
```

### Actual behavior

The `workingDirectory` property is ignored.

```
CWD = /path/to/repro <-- workingDirectory ignored
ARGS = [--nc] <-- applied
FOO = bar <-- applied
```

### Is this a regression?

No

### Are there any workarounds?

- Same result with an absolute path for `workingDirectory` is also ignored.
- Setting `rundir` in the .csproj does work but is insuficient as a workaround.

### dotnet --info output

```console
λ dotnet --info

.NET SDK:
Version: 10.0.110
Commit: f7d90799ce
Workload version: 10.0.100-manifests.1641d827
MSBuild version: 18.0.11

Runtime Environment:
OS Name: arch
OS Version:
OS Platform: Linux
RID: arch-x64
Base Path: /usr/share/dotnet/sdk/10.0.110/

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
Version: 10.0.10
Architecture: x64
Commit: f7d90799ce

.NET SDKs installed:
8.0.129 [/usr/share/dotnet/sdk]
9.0.119 [/usr/share/dotnet/sdk]
10.0.110 [/usr/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 10.0.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.29 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.18 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.10 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
None

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download
```

### IDE version

no IDE required

### Other details

Reproduced in .NET 11 preview SDK

Start with the reproduced `dotnet run --launch-profile Test` flow and the `Properties/launchSettings.json` profile, using the sample `Program.cs` to observe the current directory, arguments, and environment. Trace where `workingDirectory` is read or omitted, then verify that the profile's relative and absolute paths are honored while the existing arguments and environment variables remain applied.

Written by the indexing model from the issue text.