[release/9.0.3xx] Update dependencies from dotnet/scenario-tests

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/scenario-tests

• Subscription: 85392c56-5e51-4794-bcc8-0680cca02082
• Build: 20260919.1 (332869)
• Date Produced: September 19, 2026 5:41:08 PM UTC
• Commit: a4c8099828bc33c4bb9080d8047db9a6730eca8a
• Branch: release/9.0

• Dependency Updates:
  • From 9.0.0-preview.26407.1 to 9.0.0-preview.26469.1
    • Microsoft.SourceBuild.Intermediate.scenario-tests
    • Microsoft.DotNet.ScenarioTests.SdkTemplateTests

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[github-actions]

🔍 Build Failure Analysis

Summary — No genuine MSBuild/compile errors were found in any of the 39 published binlogs; the only “errors” are EndOfStreamExceptions from the log reader itself failing to parse three truncated/corrupted .binlog files (attempt 1 of AoT_windows_x64, FullFramework_windows_x64, and TestBuild_windows_x64), and the retried attempt (attempt 2) of each of those same legs completed with zero errors.

Root cause: Corrupted binlog from a transient/flaky Windows leg attempt (not a code issue)

For three Windows legs, only the first attempt (_1 suffix) produced a binlog that the binlog-mcp reader could not fully parse:

• 14_1_AoT_windows_x64.binlog
• 15_1_FullFramework_windows_x64.binlog
• 16_0_TestBuild_windows_x64.binlog (note: the _0 file failed here, and _1/_2 retries for this leg came back clean)

Each reports the identical failure signature:

Error when reading the file: System.IO.EndOfStreamException: Unable to read beyond the end of the stream.
   at Microsoft.Build.Logging.StructuredLogger.BuildEventArgsReader...

This is not a compiler/MSBuild error emitted by the actual build — it is the structured-log reader hitting the end of a truncated binary stream, which happens when the on-disk .binlog file was cut short (e.g. the build process/agent was killed or crashed mid-write before the log finished flushing). Every other attempt of the same three legs (14_2, 15_2/other retries, 16_1, 16_2) parsed cleanly with zero errors and zero warnings (binlog_errors returned []), and all remaining 36 binlogs across every other leg (TemplateEngine, ContainerBased, TestAsTools, linux/macOS TestBuild, etc.) also returned [] from binlog_errors with no failed-target or process-termination evidence in binlog_overview.

Because every leg has at least one clean, fully-parsed binlog with no errors, this looks like a transient/flaky Windows agent issue (an interrupted build process that left a partial log on one attempt) rather than a code defect introduced by this PR. No source change is warranted from this evidence.

Recommendation: Re-run the pipeline (or just the affected Windows legs) rather than changing code. If the corrupted-binlog pattern recurs across multiple PRs/builds, it may be worth a separate infra investigation into why these Windows agents are producing truncated binlogs on their first attempt.

---

Per-leg binlog_errors results

Leg (all attempts)	Errors
TemplateEngine (macOS x64, linux x64)	none
TestBuild (linux x64, linux arm64, macOS x64, windows x64)	none, except truncated-log noise noted above
AoT (macOS x64, windows x64)	none, except truncated-log noise noted above
FullFramework (windows x64)	none, except truncated-log noise noted above
ContainerBased (ubuntu2204DebPkg, fedora41, centosStream9, alpine322, debian12Amd64)	none
TestAsTools (windows x64)	none

---

_{🤖 Generated by the Build Failure Analysis workflow using binlog-mcp · commit c7d7f74}

🤖 Automated content by GitHub Copilot. Generated by the Build Failure Analysis workflow. · auto · 36.2 AIC · ⌖ 2.48 AIC · ⊞ 7.1K · [◷]( · ◷)