build(deps): bring UnitTests onto the same test packages as IntegrationTests (dapper)

[bgard68]

Closes the test-package drift between the two test projects on dapper.

Package	IntegrationTests	UnitTests (before)	UnitTests (after)
Microsoft.NET.Test.Sdk	18.9.0	18.8.1	18.9.0
xunit.runner.visualstudio	4.0.0	3.1.5	4.0.0

main already has both projects on 18.9.0 / 4.0.0.

Why it drifted

Residue from the pre-grouping era. #114 and #115 came off dependabot/nuget/tests/TodoApp.IntegrationTests/dapper branches and edited only the project each was named for, leaving UnitTests behind.

The grouped sweep from #126 would have caught this up — Dependabot reads dependabot.yml from the default branch, so the dapper target-branch entries apply here. That sweep ran as run 32038120956 and died in setup on a 429 downloading github/dependabot-action, during the GitHub partial outage that afternoon. Dependabot's own update jobs aren't retryable:

run 32038120956 cannot be rerun; This workflow run cannot be retried

So the sweep never opened a PR and the drift stayed. Hence this by hand.

Nothing was broken

The two test projects don't reference each other, so there was no NU1605 downgrade to trip on and dapper's CI was green throughout. The cost was quieter: unit tests were running on a test runner a major version behind the integration tests.

Scope

Only UnitTests' lock file changes. dotnet restore --force-evaluate rewrites all six on Windows, but the other five differ by line endings alone and were reverted rather than committed as churn.

Verification

Local, on the 10.0.100 SDK — pinned via a temporary global.json, since CI floats on 10.x and this machine defaults to a 10.0.400 preview:

• dotnet restore TodoApp.sln --locked-mode passes, no NU1004
• Release build clean, 0 warnings under TreatWarningsAsErrors
• 98/98 tests pass — including the 65 unit tests now discovered and run by the 4.0.0 runner, which is the only real risk in a major runner bump

🤖 Generated with Claude Code