Central package management + dependabot major/minor split (#2100 follow-up)

[erikdarlingdata]

What

• Directory.Packages.props (new): all 22 package versions live here; every csproj's PackageReference drops its Version= attribute. tools/CompactionRepro keeps its deliberate DuckDB.NET 1.5.3 pin via VersionOverride (repro tool, original-version behavior is the point).
• .github/dependabot.yml: the nuget group becomes nuget-patch-and-minor (update-types: minor, patch) so majors arrive as individual PRs — Studio's convention, breaking changes never buried in a routine batch.
• All packages.lock.json files regenerate in CPM's v2 format.

Why

PR #2100 arrived broken in the exact way per-csproj pinning invites: dependabot bumped two projects, left three others on the old version (NU1605 downgrade, warning-as-error), and stranded every transitive lock file (NU1004 in locked-mode restore). Under CPM the bump is one line in one file and every consumer moves together — the misalignment class is structurally gone, not just less likely.

Review-suggestion dispositions from #2100 (robot round 1): .gitattributes tightening — already satisfied; the repo forces * text=auto eol=crlf, and dependabot's server-side writer bypasses attributes regardless, so CPM shrinking its blast radius to one file is the real fix. deprecated/** exclusion — deliberately NOT taken: those projects are in the solution, so their lock files must stay consistent when a shared dependency bumps; under CPM they follow the central line like everything else.

No changelog entry: build-infrastructure only, nothing user-facing ships differently.

Testing

• Conversion scripted with hard asserts (conflict set must be exactly the known DuckDB pair; no Version= attrs may survive; 17 csprojs with refs, 21 total).
• dotnet restore --locked-mode passes post-conversion (the CI gate, run locally).
• Lite and Darling.Service build clean.
• The ILLink.Tasks SDK-artifact trap from Bump ModelContextProtocol and ModelContextProtocol.AspNetCore #2100 round 2 (local 10.0.300 vs CI 10.0.302) was re-checked and the one affected lock entry restored to dev's pin.
• CI is the full verdict: locked-mode restores of all five gate projects + both app builds + Darling PostgreSQL tests.

[claude]

Reviewed. This repo has no CLAUDE.md/T-SQL style guide, and the diff is entirely build-infrastructure (CPM migration) — no T-SQL touched, so no Lite/Darling SQL-parity concerns apply here. Findings below are secondary checks against the .NET/build surface.

Verified clean:

• Every PackageReference across all 21 csproj files (16 active + 5 deprecated) now resolves via Directory.Packages.props; grepped the whole tree for leftover inline Version= attributes on PackageReference and found none outside the deliberate VersionOverride on tools/CompactionRepro.
• Directory.Packages.props's 22 PackageVersion entries map 1:1 onto the 22 distinct package names actually referenced anywhere in the solution — no orphans, nothing missing.
• All 9 packages.lock.json files consistently bumped "version": 1 → 2 (the CPM lock format).
• Cross-checked shared packages between Lite and Darling (Microsoft.Data.SqlClient, ScottPlot.WPF, Hardcodet.NotifyIcon.Wpf, Velopack, ModelContextProtocol*) — all pull the same central version now, which structurally improves parity vs. the old per-csproj pinning that let Bump ModelContextProtocol and ModelContextProtocol.AspNetCore #2100 happen.
• nuget.config's single-source pinning + package source mapping is untouched and still applies.
• tools/CompactionRepro's VersionOverride="1.5.3" against a central DuckDB.NET.* version of 1.5.5 works correctly since CentralPackageVersionOverrideEnabled is left at its default (enabled) — not disabled anywhere in the tree.
• dependabot.yml's new nuget-patch-and-minor group (patterns *, update-types minor/patch) correctly excludes majors from grouping, matching the stated "majors get their own PR" intent — valid Dependabot group syntax.

One low-confidence, non-blocking observation: in the three deprecated net10.0 (non-Windows TFM) lock files — deprecated/Installer/, Installer.Core/, Installer.Tests/ — the CentralTransitive entries for Microsoft.Extensions.Logging.Abstractions and System.Security.Cryptography.ProtectedData show "requested": "[10.0.10, )" but "resolved" stays at the old transitive versions (10.0.3/9.0.13), unlike every net10.0-windows7.0 lock file where the same packages resolve all the way up to the central 10.0.10. This is most likely just NuGet's normal transitive resolution (no CentralPackageTransitivePinningEnabled, so the central version is a floor/candidate rather than a forced bump, and something in that TFM's graph caps it lower) rather than a bug — and it's scoped to deprecated code — but since the PR's stated goal is "every consumer moves atomically," it's worth a quick sanity glance to confirm CI's --locked-mode restore is happy with it (the PR description says it is).

No correctness, security, or performance concerns found otherwise.