[automated] Merge branch 'release/9.0.1xx' => 'release/9.0.3xx'

[github-actions]

I detected changes in the release/9.0.1xx branch which have not been merged yet to release/9.0.3xx. I'm a robot and am configured to help you automatically keep release/9.0.3xx up to date, so I've opened this PR.

This PR merges commits made on release/9.0.1xx by the following committers:

• dotnet-sb-bot
• mthalman
• dotnet-maestro[bot]
• marcpopMSFT
• dotnet-bot
• nagilson
• github-actions[bot]
• vseanreesermsft
• ellahathaway
• SimonZhao888
• joeloff
• lbussell
• wtgodbe
• dsplaisted
• DonnaChen888

Instructions for merging from UI

This PR will not be auto-merged. When pull request checks pass, complete this PR by creating a merge commit, not a squash or rebase commit.

If this repo does not allow creating merge commits from the GitHub UI, use command line instructions.

Instructions for merging via command line

Run these commands to merge this pull request from the command line.

git fetch
git checkout release/9.0.1xx
git pull --ff-only
git checkout release/9.0.3xx
git pull --ff-only
git merge --no-ff release/9.0.1xx

# If there are merge conflicts, resolve them and then run git merge --continue to complete the merge
# Pushing the changes to the PR branch will re-trigger PR validation.
git push https://github.com/dotnet/sdk HEAD:merge/release/9.0.1xx-to-release/9.0.3xx

or if you are using SSH

git push git@github.com:dotnet/sdk HEAD:merge/release/9.0.1xx-to-release/9.0.3xx

After PR checks are complete push the branch

git push

Instructions for resolving conflicts

⚠️ If there are merge conflicts, you will need to resolve them manually before merging. You can do this using GitHub or using the command line.

Instructions for updating this pull request

Contributors to this repo have permission update this pull request by pushing to the branch 'merge/release/9.0.1xx-to-release/9.0.3xx'. This can be done to resolve conflicts or make other changes to this pull request before it is merged.
The provided examples assume that the remote is named 'origin'. If you have a different remote name, please replace 'origin' with the name of your remote.

git fetch
git checkout -b merge/release/9.0.1xx-to-release/9.0.3xx origin/release/9.0.3xx
git pull https://github.com/dotnet/sdk merge/release/9.0.1xx-to-release/9.0.3xx
(make changes)
git commit -m "Updated PR with my changes"
git push https://github.com/dotnet/sdk HEAD:merge/release/9.0.1xx-to-release/9.0.3xx

or if you are using SSH

git fetch
git checkout -b merge/release/9.0.1xx-to-release/9.0.3xx origin/release/9.0.3xx
git pull git@github.com:dotnet/sdk merge/release/9.0.1xx-to-release/9.0.3xx
(make changes)
git commit -m "Updated PR with my changes"
git push git@github.com:dotnet/sdk HEAD:merge/release/9.0.1xx-to-release/9.0.3xx

Contact .NET Core Engineering (dotnet/dnceng) if you have questions or issues.
Also, if this PR was generated incorrectly, help us fix it. See https://github.com/dotnet/arcade/blob/main/.github/workflows/scripts/inter-branch-merge.ps1.

---

Tactics

Summary

This is an automated inter-branch merge PR bringing commits from release/9.0.1xx into release/9.0.3xx. The substantive changes are in the dotnet publish container support (Microsoft.NET.Build.Containers): (1) blob downloads were not verifying the SHA-256 digest of cached or downloaded content, meaning corrupted or stale cache entries could silently produce invalid container images; and (2) two Registry constructor overloads were not forwarding the retryDelayProvider parameter to the underlying constructor, silently disabling retry-delay customization in those call paths. Both are correctness fixes appropriate for servicing. Additional changes consist of routine dependency version bumps and pipeline YAML updates pulled in by the merge.

Customer Impact

Customers using dotnet publish with container publishing (--os, --arch, or container-related properties) on SDK 9.0.1xx could receive silently incorrect container images if their local blob cache contained corrupted or mismatched content, with no error surfaced. The retry-delay bug affects callers that supply a custom retryDelayProvider via the Registry(string, ILogger, IRegistryAPI, RegistrySettings?, Func<TimeSpan>?) or Registry(Uri, ILogger, IRegistryAPI, RegistrySettings?, Func<TimeSpan>?) constructors — in practice this is mostly internal/test code, but it could cause unexpected retry behavior in CI or constrained network scenarios. No known workaround for the digest-verification gap other than clearing the Containers cache manually.

Regression?

Unknown — not enough information in the PR or linked issues to pinpoint the exact SDK version or PR that introduced the digest-verification gap or the retryDelayProvider forwarding omission. The digest verification improvement is a new correctness enforcement, not a rollback of a previous behavior.

Testing

• Unit tests updated in test/Microsoft.NET.Build.Containers.UnitTests/RegistryTests.cs: two existing retry tests (DownloadBlobAsync_RetriesOnFailure, DownloadBlobAsync_ThrowsAfterMaxRetries) were updated to use real SHA-256 digests matching the test payloads, validating that the new CopyToAndVerifyAsync digest check passes on a successful download path and throws on mismatch.
• CI validation on the PR branch (108 commits merged from 9.0.1xx).
• No explicit mention of manual repro steps or private lab testing in PR comments.

Risk

Low–Medium. The code changes are scoped to the container publishing component (src/Containers/) and do not touch the core MSBuild build/restore paths. The digest-verification addition increases correctness with low regression risk, but it does introduce a new code path (CryptoStream + InvalidDigestException) that could surface failures for customers whose existing cache contains blobs written without proper content. The TempPath change (from a shared Containers/Temp subfolder to a unique CreateTempSubdirectory()) is a behavioural change in temp file placement that could surface permissions or cleanup issues in constrained environments. The retryDelayProvider fix is a one-line constructor forwarding correction with negligible risk. Overall risk is low-medium given the containment to a single feature area and the test coverage present.

[nagilson]

/tactics