Pin the dependency graph with lock files

[ivanvyd]

Closes the last of the Scorecard findings — the nine nugetCommand not pinned by hash alerts.

Central package management already fixes the direct versions. The transitive graph underneath them was free to move between one restore and the next, which is what those alerts point at.

One property, no workaround

<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>

That writes the resolved graph to a packages.lock.json beside each project — 26 of them, committed. Every restore in CI, in publish.yml, and in the two sample Dockerfiles now passes --locked-mode.

The rest of the hand-written diff is five one-word changes. No csproj gymnastics: I briefly added some and then removed them, because they turned out to be fixing a problem I had caused myself (below).

Verified in both directions

A control that only ever passes isn't a control.

	result
clean restore, locked mode	passes
one version moved in Directory.Packages.props, locks not regenerated	fails, NU1004

The Dockerfiles needed the lock file too

They restore against the manifests alone to keep the layer cacheable, copying only Directory.*.props and the csproj. With locked mode there's nothing to check against, so the build fails. Both now copy packages.lock.json next to the csproj.

Both images were built to prove it, and the WebApi one was run:

GET /healthie -> HTTP 200
warn: Healthie.Api.Diagnostics.UnauthenticatedSurfaceWarning[4001]
      Healthie: 6 endpoint(s) that can change a pulse checker are reachable without
      authenticating -- healthie/{checkerName}/interval, .../reset, .../start, ...

That is also the first time the startup warning from #42 has been seen firing in a real container rather than a unit test.

A mistake worth recording

My first attempt failed with Invalid framework identifier '', and I misdiagnosed it as the test projects' <TargetFramework /> / <TargetFrameworks /> clearing. I restructured Directory.Build.props and both csproj files to work around it.

The actual cause: I had written --locked-mode inside an XML comment in Directory.Build.props, so the whole file failed to load and no properties were set. I have a memory entry about -- in XML comments from earlier in this project and walked into it again.

All the restructuring is reverted. <TargetFramework /> works fine with lock files.

Cost, stated plainly

Changing a version in Directory.Packages.props now also means regenerating the locks or restore fails. Dependabot handles this itself; a human does it with a force-evaluate restore. The comment in Directory.Build.props says so.

473 tests green on net8.0 and net10.0, 0 errors / 0 warnings.