Upgrade references through one Core module that both front ends call - #852

The CLI and MCP each orchestrated an upgrade themselves, and they had drifted apart. Upgrade also re-located each reference's version once per target framework, using two full MSBuild evaluations each time. This PR moves upgrading behind one Core interface, IReferenceUpgrader, which takes a reference and every project that declares it.

What changes

Commit 1: one evaluation per project. IProjectEvaluator.GetPackageVersions replaces GetVersionVariables and GetGlobalPackageReferenceFile. It returns the item that sets each package's version: its file, its expression, its evaluated range and the version variable behind it. A literal location now carries its declaration, so the --no-restore central-package update writes the file the evaluator found. It no longer searches each Directory.Packages.props above the project for the package name as text.

Commit 2: IReferenceUpgrader replaces IDotNetPackageService. The module now owns three rules the CLI used to apply around each call:

• Range. A declared upper bound that the new version still satisfies is kept. It is read from what is written at the version location, not from analysis.
• Remove before add. A package is removed before being added back in a project that isn't SDK-style. This is now checked through IFileSystem.
• Kind inference when the kind is omitted.

Each project's version location is found once per upgrade. A location shared by several projects is written once, and each project is restored once.

The result is one outcome per project: upgraded, already current, or failed. Each outcome carries its own warnings, and one project failing doesn't stop the others. UpgradeVersionRange, IsProjectSdkStyle, RemovePackage and IWarningReporter are removed.

I planned three commits, but swapping the interface and switching the front ends had to land together to keep the build green.

Behaviour changes

• MCP update_package applies the same rules as the CLI.
  • It keeps a declared upper bound: [6.0.13, 7.0.0) → [6.0.36, 7.0.0). It used to write a bare 6.0.36.
  • It removes a package before adding it back in projects that aren't SDK-style.
  • It returns warnings in the tool result.
  • It says when the package is already at the requested version.
• A transitive package pinned by a central PackageVersion range keeps that range's upper bound. It used to be overwritten, because the policy ignored declared ranges for transitive packages.
• A version location that already holds the version is reported as already current and not restored. One written by an earlier upgrade in the same run still restores each project that hasn't been restored since.
• The CLI makes one upgrade call per package across all its projects and target frameworks. It prints one line per project instead of one per (project, target framework).
• An unreadable project file no longer triggers remove-before-add. The upgrade reports its own error instead. A file that isn't valid XML is still treated as not SDK-style.
• Core's public API. IDotNetPackageService (shipped) and IWarningReporter (unshipped) are removed. IReferenceUpgrader, ReferenceUpgrade, UpgradeProject, ProjectUpgradeResult and UpgradeOutcome are added.

Tests

• DotNetPackageServiceTests is now ReferenceUpgraderTests. New tests cover:
  • a shared location written once across projects in one call;
  • an already-current location;
  • one project's failure not stopping the others.
• The UpgradeVersionRange, VersionLocator and SDK-style cases now go through IReferenceUpgrader against MockFileSystem.
• UpgradePackagesTests covers only prompting and console output, using a fake upgrader.
• McpServerTests checks that update_package keeps a declared upper bound, using a real upgrader.

dotnet test passes on net8.0, net9.0 and net11.0 (1,137 / 1,116 / 1,116 passed, 1 pre-existing skip each).

🤖 Generated with Claude Code