CI: enable NuGet caching to cut restore from ~60s

[erikdarlingdata]

Summary

The Restore dependencies step on every CI run takes ~1 minute because nothing caches NuGet packages between runs. setup-dotnet@v4 has a built-in cache option that uses packages.lock.json as the cache key — on a hit, restore drops to ~5–10s.

Changes

• Add cache: true and cache-dependency-path: '**/packages.lock.json' to actions/setup-dotnet@v4 in both build.yml and nightly.yml.
• Generate packages.lock.json for Dashboard, Lite, Installer, Installer.Core, and Lite.Tests via dotnet restore --use-lock-file.
• Switch the restore commands to --locked-mode so CI fails fast if someone forgets to commit an updated lock file (instead of silently resolving transitive packages and bypassing the cache key).

The lock files double as a supply-chain check — package versions are now pinned across the graph, not just the direct refs in csproj.

Notes

• First run after merge will not hit the cache (cache must be populated). Expect ~60s restore on PR Speed up Lite tests: enable parallelization + share DuckDB in FinOpsTests #924-style commits, then ~5-10s on subsequent runs with the same lock files.
• If a contributor adds/updates a package, they need to either run dotnet add package X (auto-updates lock file) or dotnet restore --use-lock-file manually before pushing. CI will fail with --locked-mode if the lock file is stale, which is the desired safety.

Test plan

• dotnet restore --locked-mode works locally for all 4 projects
• dotnet build --no-restore works locally after locked restore
• CI restore time drops on the second run after merge

🤖 Generated with Claude Code