Use dotnet cake for SDK provisioning to fix workload resolver issues

[PureWeen]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Description

MSBuild caches workload manifests at evaluation time and cannot refresh mid-build. When the SDK bundles stale manifests from older preview bands (dotnet/sdk#53234), this causes NETSDK1178 errors because the cached state references non-existent packs.

MAUI's InitInternalTooling target (eng/Tools.props) provisions workloads inside AfterTargets="Restore" — but by that point MSBuild already cached the stale workload state. The MSBuild SDK explicitly states: "For workload installation actions, we expect to be running under a NEW PROCESS."

This PR aligns MAUI's CI with that design by using dotnet cake (which runs each task as a separate dotnet process) instead of build.sh (single MSBuild process) for SDK provisioning.

Changes

1. Switch BuildTasks steps to dotnet cake --target=dotnet-buildtasks — Provisions SDK and builds BuildTasks as separate processes (fresh workload resolver state each time)
2. Add dotnet cake --target=dotnet before Pack stages — Provisions SDK/workloads before the pack step
3. Add SkipInitInternalTooling condition to eng/Tools.props — Prevents redundant DotNet.csproj re-runs that cause MSB3026 file-lock timeouts when Cake already provisioned
4. Pass /p:SkipInitInternalTooling=true from all pipeline steps that run after Cake provisioning
5. Add _CleanStaleWorkloadManifestBands target to DotNet.csproj — Removes stale manifest bands as defense-in-depth (becomes a no-op once .NET 11 Preview workload manifests use wrong feature band in .NET SDK archives sdk#53234 fix flows through)
6. Remove redundant build.cmd SDK install from Windows device tests (Cake handles it)

Why This Works

Device tests already use this exact dotnet cake pattern and it works. The Cake build file (eng/cake/dotnet.cake) runs DotNet.csproj as process #1 (provisioning), then BuildTasks.slnf as process #2 (building) — each with fresh workload resolver state.

Files Changed

File	Change
eng/Tools.props	SkipInitInternalTooling condition
src/DotNet/DotNet.csproj	_CleanStaleWorkloadManifestBands target
eng/pipelines/arcade/stage-build.yml	Cake + SkipInitInternalTooling
eng/pipelines/arcade/stage-pack.yml	Cake provisioning + SkipInitInternalTooling
eng/pipelines/arcade/stage-helix-tests.yml	Cake + SkipInitInternalTooling
eng/pipelines/arcade/stage-unit-tests.yml	Cake provisioning
eng/pipelines/arcade/stage-device-tests.yml	Cake + SkipInitInternalTooling + remove redundant build.cmd

Context

• Validated on release/11.0.1xx-preview4 branch (PR [release/11.0.1xx-preview4] Update dependencies from dotnet/android, dotnet/dotnet #35171) — all Build, Pack, and Helix jobs pass
• Root cause analysis: dotnet/sdk#53234 (stale manifest bundling, already fixed upstream)
• dotnet/android and dotnet/macios don't hit this because they use Make-based builds with natural process separation

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35264

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35264"

[PureWeen]

Superseded by #35330 which merges all preview4 changes (including these Cake/SkipInitInternalTooling fixes) into net11.0.