🔒 Fix the Meta Test build (vulnerable packages + CS9113 in scaffolds)

[AntPolkanov]

1. What triggered this change? (PBI link, Email Subject, conversation + reason, etc)

✏️ The Meta Test workflow has been red on main since #624 (12 Jun), so every PR inherits a failing check - e.g. #630, a docs-only PR. Nothing in those PRs caused it; both problems below are pre-existing on main.

2. What was changed?

✏️ Two independent problems, both of which only bite in Release because Directory.Build.props sets TreatWarningsAsErrors there.

1. Vulnerable transitive packages (34 restore errors)

NuGet audit turned four packages into NU1902/NU1903 errors, failing restore before compilation:

Package	Was	Now	Advisory
OpenTelemetry.Exporter.OpenTelemetryProtocol	1.15.0	1.15.3	GHSA-4625-4j76-fww9, GHSA-mr8r-92fq-pj8p, GHSA-q834-8qmm-v933
OpenTelemetry.Extensions.Hosting	1.15.0	1.15.3	pulls OpenTelemetry.Api past GHSA-g94r-2vxg-569j
Microsoft.OpenApi	2.0.0	2.7.5	GHSA-v5pm-xwqc-g5wc (high)
MessagePack	2.5.192	2.5.302	GHSA-hv8m-jj95-wg3x + 8 more

Notes on the choices:

• Microsoft.OpenApi and MessagePack are transitive only (Microsoft.AspNetCore.OpenApi → Microsoft.OpenApi; Aspire.Hosting → StreamJsonRpc → MessagePack). Under CPM a PackageVersion alone does nothing for a transitive package, so each also gets a direct PackageReference - the same workaround already in place for KubernetesClient. Both are marked TODO to remove once upstream bumps.
• Bumping Microsoft.AspNetCore.OpenApi does not help - even 10.0.10 still declares Microsoft.OpenApi 2.0.0, so Dependabot's #619 would not have fixed this.
• The OpenTelemetry.Instrumentation.* packages version independently and have no 1.15.3 - bumping them to match produced NU1603. They stay at 1.15.0 and resolve OpenTelemetry.Api to 1.15.3 through the exporter anyway.
• MessagePack stays on the 2.5 line; 3.x is a major bump that StreamJsonRpc 2.22.23 is not built against.

2. CS9113: Parameter 'dbContext' is unread in the generated scaffolds

Once restore succeeded, Build after a query still failed. The query/command item templates inject IApplicationDbContext dbContext into a handler whose body is throw new NotImplementedException(), so the parameter is never read.

This is a toolchain regression, not a template change - the scaffolds have not changed since #439. Verified by building the same generated file on both SDKs:

SDK 10.0.202 -> CS9113 occurrences: 0
SDK 10.0.302 -> CS9113 occurrences: 2

CI resolves 10.0.302, which is why the last green run was 10 Mar.

CS9113 is suppressed around the scaffolded handler only, rather than added to the global NoWarn list. A template propagates to every downstream consumer, and an unused injected dependency in real code is worth flagging - so the diagnostic stays on everywhere except the stub, where the comment tells the developer to delete the pragmas once they use dbContext.

Test plan

Ran the full Meta Test locally on SDK 10.0.302 (the exact version CI resolves):

Step	Before	After
Build fresh Project (Debug)	68 warnings	0 warnings, 0 errors
Build after a query (Release)	34 errors	0 warnings, 0 errors
Build after a command (Release)	not reached	0 warnings, 0 errors

Also on this branch:

• dotnet test --configuration Release - 34 domain + 9 architecture + 10 integration tests pass.
• Confirmed the resolved graph really is patched: Microsoft.OpenApi 2.7.5, MessagePack 2.5.302, OpenTelemetry.Api 1.15.3 across all projects.
• Pinning Microsoft.OpenApi ahead of the version Microsoft.AspNetCore.OpenApi 10.0.3 was compiled against is the one real runtime risk here, since a break would surface only when the document is generated. MapOpenApi() is unconditional in Program.cs but no test covered it, so I added a temporary integration test hitting /openapi/v1.json - it returned a valid document containing /api/teams. Removed again before committing, though it may be worth adding for real in a follow-up.

3. Did you do pair or mob programming?

✏️ N/A