fix(install): align partial-update operation order with Composer

Three coordinated changes to make `update --with-dependencies` produce
the same operation trace Composer emits:

- LockFileGenerationRequest gains a previous_lock field. When a
  resolved package matches an entry in the old lock at the same name +
  version_normalized, its relationship-shaped fields (require /
  require-dev / conflict / replace / provide / suggest) are carried
  over verbatim. Source/dist refs and version-shaped fields still
  refresh from upstream metadata so dev packages can still pick up new
  commits. Without this carry-over, partial updates regenerated lock
  entries from upstream COMPOSER repo definitions, which can declare
  different requires than the lock — and topological_sort then sees a
  graph Composer's transaction never built.

- Transaction's topological_sort and get_root_packages now expand
  replace/provide targets when matching `require` links to result
  packages, mirroring Composer's getProvidersInResult. Previously a
  package was only treated as required when matched by its own name,
  so packages reached only via replace/provide were mis-classified as
  roots and the DFS stack visited deps in the wrong order.

- compute_operations iterates installed.json in reverse when emitting
  removals, mirroring Composer's array_unshift onto operations. Two
  co-orphaned packages otherwise emit removals in the wrong order vs
  Composer's trace.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions