Convert to Central Package Management

Centralize package versions in Directory.Packages.props while preserving project behavior and producing reviewable before/after evidence.

Choose a mode first

Do this before running builds or changing files.

Guard mode -- If any in-scope project uses packages.config, stop. Explain that CPM requires PackageReference and recommend migrating first. Do not create or modify files.
Package-maintenance mode -- A request to update, align, bump, or sync packages authorizes those package edits, not CPM conversion. Audit the named scope, resolve the requested versions, update existing project/shared version declarations, and restore/build every affected CLI target from the directory that establishes its applicable global.json. Ask only when the version or alignment policy is ambiguous. Do not create or modify Directory.Packages.props, remove versions for CPM, or capture conversion artifacts. Complete the package work, then recommend CPM as the durable follow-up.
Conversion mode -- Use only when the user explicitly asks to adopt, enable, or convert to CPM. Follow the workflow below.

If the scope is unclear, ask once before proceeding.

Guard: use a minimal scoped detection pass, then answer and stop.
Package maintenance: use a compact audit, edit only the requested package versions in their existing locations, validate affected targets, then recommend CPM. Do not read conversion references or enter the conversion workflow.
Conversion: batch the preflight, baseline, audit/mutation, final validation, and report work to avoid redundant turns. Revisit a stage only when new CPM-specific evidence requires a targeted follow-up.