Same-stack version uplift (e.g

Uplift `legacy/$1` from **$2** to **$3** — same stack, newer version.

This is **not** `/modernize-transform`. There you extract intent and rewrite
idiomatically. Here the code is good; it just needs to run on a newer
runtime. You **preserve structure and make the smallest diffs that compile
and behave identically on the target**, driven by the *known* breaking
changes between $2 and $3 — not by re-deriving the business logic.

The potential advantage of a same-stack uplift: **if both runtimes execute in
this environment, the same test suite can run on both** and your equivalence
proof becomes a real differential test (run on both, diff the results). That
is the strong case — but it is **not always available**, and the command is
explicit about when it is:

- It depends on the stack. .NET can multi-target one test project to both
  framework monikers (`<TargetFrameworks>net48;net8.0</TargetFrameworks>`),
  **but `net48` only executes on Windows/Mono** — on a Linux/macOS box or most
  CI sandboxes the old leg cannot run. Java 8→17 is not one suite over two
  targets at all — it is the whole build run twice under two JDK toolchains.
  Python 2→3 cannot import the same un-rewritten module under both
  interpreters. So "true dual-run" is the *best* case, common only for
  .NET-on-Windows.
- When both runtimes are **not** runnable here, equivalence degrades — exactly
  like `/modernize-transform` — to characterization tests pinned to
  recorded/expected outputs on the target only. That is fine; it just must be