fix(remediation): parent-update targets render a foreign package's version under the parent's name

parent-update targets store the parent in package but the child's version in targetVersion, because the target means "refresh the child through the parent's existing range" rather than "upgrade the parent". Every renderer treats targetVersion as this package's version, so the output says something that is not true.

#1113 fixed the emitted command by splitting the keyspace, so plan.command is now correct. It deliberately left the target shape alone, and its test asserts the current shape, so this is the remaining half rather than a regression.

Running the #1007 repro against main plus #1113:

one child (form-data):
  axios  parent-update  current=1.16.1  target=4.0.6   breakingBadge=true

two children (form-data, follow-redirects):
  axios  parent-update  current=1.16.1  target=1.15.11  breakingBadge=false
  axios  parent-update  current=1.16.1  target=4.0.6    breakingBadge=true

Two separate problems.

The version is a foreign package's. The terminal table renders axios 1.16.1 -> 4.0.6, the JSON carries {"package":"axios","targetVersion":"4.0.6","kind":"parent-update"}, and isBreakingUpgrade compares axios 1.16.1 against form-data's 4.0.6, sees the major jump and stamps a breaking badge on an upgrade that is not happening. This is the second half of what @alamb-hex originally reported, that the output implies axios needs a three-major upgrade.

One target per child. Keying per child means several findings behind one parent each produce a target carrying package: "axios". That is two axios rows where the first reads as a downgrade from 1.16.1 to 1.15.11, npm update axios spawned twice by --fix, and two cve.fix.applied audit records carrying versions that belong to other packages.

The shape question is where the child's version should live. SuggestedFixTarget has no field for "the child being refreshed", so either targetVersion becomes the parent's own version (unchanged, since the parent is not being upgraded) and the child moves to a new field the renderers show in Context, or the renderers learn to special-case parent-update. The first is more honest about what the target means; the second is a smaller diff. Either way it touches the JSON shape, the terminal table, the HTML report and the SARIF and CycloneDX fix metadata added in #1145, so it wants deciding before it is written.

Credit to @osfv for the diagnosis in #1113 and to @alamb-hex for the original report.

Start by reviewing the target shape left by #1113 and the renderers affected by this issue: terminal, JSON, HTML, SARIF, and CycloneDX metadata from #1145. Use the #1007 reproduction to compare parent-update output for one and multiple children. Done means the target and every renderer agree on the child version and no longer report duplicate or misleading parent upgrades.