chore(ci): log requested vs selected .NET SDK in dotnet-integration

[roger-zhangg]

Issue #, if available: n/a

Description of changes

Adds a diagnostic step to the dotnet-integration job that logs the SDK version the matrix requested next to the one the .NET CLI actually selected.

The matrix has three legs — 6.0.x, 8.0.x, 10.0.x — but actions/setup-dotnet adds an SDK to DOTNET_ROOT rather than replacing what the runner image already ships. The ubuntu-24.04 image comes with SDKs 8.0.x, 9.0.x and 10.0.x preinstalled in /usr/share/dotnet, and there is no global.json in this repo, so the CLI's resolver picks the highest installed SDK. The requested SDK is downloaded and then never used.

Net effect: all three legs run on the newest SDK, so the matrix axis currently has no effect. Corroborating evidence from a recent run — the dotnet 6.0.x leg executed test_with_custom_runtime_1_dotnet10 and passed, which is not possible on SDK 6.

This matters beyond tidiness. GlobalToolInstallAction installs Amazon.Lambda.Tools unpinned:

self.subprocess_dotnet.run(["tool", "install", "-g", "Amazon.Lambda.Tools", "--ignore-failed-sources"])

NuGet resolves the newest version (7.0.0) and then checks TFM compatibility, with no backtracking to an older compatible version. 7.0.0 dropped net6.0/net7.0, shipping only tools/net8.0 and tools/net10.0. Under SDK 10 the restore targets net10.0 and succeeds; under SDK 6 it targets net6.0 and fails:

error NU1202: Package Amazon.Lambda.Tools 7.0.0 is not compatible with net6.0 (.NETCoreApp,Version=v6.0) / any.
  Package Amazon.Lambda.Tools 7.0.0 supports:
    - net10.0 (.NETCoreApp,Version=v10.0) / any
    - net8.0 (.NETCoreApp,Version=v8.0) / any

Because CI never actually selects SDK 6, it cannot observe this. aws-sam-cli does — its --use-container builds use public.ecr.aws/sam/build-dotnet6, a single-SDK image (6.0.428 [/var/lang/bin/sdk]) with no newer SDK to roll forward to. Its nightly build-x86-container-2 job has failed every night since Amazon.Lambda.Tools 7.0.0 was published on 2026-07-01T14:55Z.

Note this is only the toolchain half. The test projects genuinely target net6.0 (WithDefaultsFile6/WithDefaultsFile.csproj sets <TargetFramework>net6.0</TargetFramework>), and SDK 10 builds them fine. What is missing is coverage of net6.0 as the SDK/restore context — the only configuration where 7.0.0 fails.

This PR only adds logging so the discrepancy is visible in job output. Making the 6.0.x leg genuinely run on SDK 6 requires a global.json (or DOTNET_ROLL_FORWARD=Disable); that is a behavior change and is intentionally left out of this diagnostic-only PR.

Description of how you validated changes

Reproduced the runner's SDK layout in a container (SDK 6 installed alongside SDK 10 in a shared DOTNET_ROOT, no global.json) and ran the exact commands the new step runs:

matrix requested : 6.0.x
dotnet --version : 10.0.302
installed SDKs   :
6.0.428 [/usr/share/dotnet/sdk]
10.0.302 [/usr/share/dotnet/sdk]

Confirmed the consequence with the same unpinned install command in both configurations, one runner:

CASE 1 - no global.json (current CI):        selected 10.0.302 -> Amazon.Lambda.Tools 7.0.0 installed OK
CASE 2 - global.json pinning 6.0.428:        selected 6.0.428  -> NU1202, install fails

Also verified public.ecr.aws/sam/build-dotnet6:latest-x86_64 reports 6.0.428 [/var/lang/bin/sdk] as its only SDK, and that pinning (--version "6.*" → 6.0.6) installs cleanly inside it.

Workflow YAML parses; the added step uses shell: bash so it behaves identically on the windows-latest legs. No test or product code touched.

Checklist

• Review the generative AI contribution guidelines

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[Vandita2020]

It is a test PR. No need to merge