chore(deps): bump NuGet packages to latest, and unblock the weekly Dependabot nuget job #683

Why now

The nuget Dependabot job has failed every week since ~2026-08-28 (last success 2026-08-21). Its check run attaches to whatever main's HEAD is at the time, so it currently shows as a red cross on an unrelated merge commit.

Diagnosed root cause, with evidence:

• Microsoft.CodeAnalysis.CSharp 5.0.0 is a direct reference in exactly one project, tests/Cluckwork.Application.Tests. A 5.0.0 → 5.9.0 minor bump is a valid target for the nuget-minor-patch group, whose pattern is ["*"].
• Microsoft.CodeAnalysis.CSharp 5.9.0's nuspec requires Microsoft.CodeAnalysis.Common at exactly [5.9.0, 5.9.0] — that exact pin is the = 5.9.0 in Dependabot's dependency_not_found error.
• In Cluckwork.Api, Common exists only transitively, via Microsoft.EntityFrameworkCore.Design 10.*, whose Roslyn chain exact-pins it at = 5.0.0 (three packages do: CodeAnalysis.CSharp, CodeAnalysis.CSharp.Workspaces, CodeAnalysis.Workspaces.Common).
• Both 5.9.0 packages exist and download fine (http=200 from api.nuget.org), so this was never a missing package.

Reproduced in a two-line scratch project (EntityFrameworkCore.Design 10.* + Common [5.9.0]), which emits three NU1608 constraint violations — the same collision.

What this issue does

Bump every outdated package that can move, verify against a real baseline, and let the pending update disappear.

Baseline captured on main (94b188f7) before any change: dotnet test Cluckwork.sln → exit 0, 2278 tests (Domain 365, AppHost 10, Application 234, Api.Integration 1669, the last against real Postgres via Testcontainers).

Moving (19 packages, incl. transitives):

• Floating already (* ranges — lock regeneration only): StackExchange.Redis 3.1.13→3.1.31, OpenTelemetry ×7 1.17.0→1.18.0, Google.Protobuf 3.36.0→3.36.1
• Pinned, explicit .csproj edits: Aspire.Hosting.{JavaScript,PostgreSQL,Redis,Testing} 13.5.1→13.5.3, Microsoft.CodeAnalysis.CSharp 5.0.0→5.9.0

Deliberately NOT bumped — recorded, not overlooked

• Microsoft.OpenApi 2.12.2 → 3.10.2. A major, and one previously spiked and found provably non-trivial. It needs its own spike and its own decision; folding a hard major into a routine bump would make both unreviewable.
• OpenTelemetry.Instrumentation.EntityFrameworkCore 1.16.0-beta.1 — dotnet list package --outdated reports "Not found at the sources". A prerelease that may have been unlisted. Worth understanding on its own rather than bumping blind.

Consequences worth a reviewer's attention

1. CodeAnalysis.Common now resolves differently per project — 5.9.0 in Application.Tests, still 5.0.0 in Api/Infrastructure (EF Core Design's exact pin). Correct and expected; per-project graphs are independent.
2. A prerelease enters a committed lock file: Microsoft.CodeAnalysis.Analyzers 3.11.0 → 5.9.0-1.26328.17, forced by CodeAnalysis.CSharp 5.9.0's own nuspec. Test-project only, nothing shipped — but it should be a decision, not a surprise.
3. This may not fully fix the Dependabot job. It removes the pending update, so there should be nothing left to attempt — but the exact-pin split in (1) still exists, and only the next weekly run can confirm. If it fails again, the fallback is a narrowly scoped ignore in dependabot.yml, with the trade-off written beside it: ignore suppresses security updates too, not just version updates.

The blocking CI vulnerability gate (dotnet list package --vulnerable → vuln-gate.mjs, #146) is independent of Dependabot and unaffected throughout — this is a degraded update path, not an open hole.

Acceptance

• dotnet build Cluckwork.sln — 0 warnings, 0 errors (warnings-as-errors)
• dotnet test Cluckwork.sln — no regression against the 2278-test baseline
• Every packages.lock.json regenerated and committed in the same commit (CI restores --locked-mode; a stale lock is NU1004)
• The next weekly Dependabot nuget run observed, and its result recorded here