feat: add Root column showing the top-level dependency behind each finding

[fabioemoutinho]

Closes #923

Summary

• Vulnerable transitive dependencies gave no indication of which top-level (direct) dependency pulled them in.
• Adds a Root column across all report surfaces:
  • Terminal table: compact name +N form (e.g. express +2) when multiple direct dependencies pull in the same vulnerable transitive package.
  • JSON output (--json / report data): full rootDependencies: string[] array on each finding.
  • HTML report: lists every root dependency name in full (not truncated), since there's more horizontal room.
• Direct dependencies and findings with no path data show - (there's no meaningful "root" distinct from the package itself).
• New getRootDependencies(finding) helper in src/utils/finding.ts, mirroring the existing getPrimaryParent convention (same length-based filtering of degenerate direct-dependency paths), and gated on relationship === "transitive" so a package classified direct never shows a contradictory root even if it's also reachable via another root's transitive chain.
• Renamed the HTML detail view's Parent: label to Root: so it matches the new column instead of using two terms for the same concept.

Test plan

• getRootDependencies unit tests: single root, multiple unique roots across several paths, degenerate direct-dependency path, empty paths, mixed direct+transitive-path edge case.
• formatRootDependencySummary unit tests: single name, name +N for multiple roots, - fallback, mixed direct+transitive-path edge case.
• printTable tests: Root column header present, name +N compact form, - for direct dependencies.
• HTML report tests: Root header present, full comma-separated list of root names, - fallback for direct dependencies, Root: detail label.
• serializeFinding test updated to assert rootDependencies is included.
• Full existing test suite passes with no regressions.

[sonukapoor]

Fabio, this is a genuinely useful addition - showing the top-level dependency behind a transitive finding is exactly the kind of actionable context we like to give people, and I love that you covered all three surfaces (terminal, JSON, HTML) with tests to match. I pulled it down and tried it locally and it reads really well.

Just a couple of small things and then I think it's good to go, both left as inline notes. The main one is an edge case where a direct dependency can end up showing a transitive root; the other is a tiny naming consistency nit. Neither is a big lift.

One admin thing whenever you get a chance: could you add Closes #923 to the PR description? I opened that issue to track the feature. Thanks so much for this - really nice work.

[sonukapoor]

Reran the repro locally and it's sorted - the contradictory row is gone, direct findings show a dash, and transitive ones still resolve their root.

One more you might want to grab while you're in here, not a blocker: the expanded HTML detail row still shows a single root (it reads from primaryParent, so just the first path), while the new column can show name +N across all paths. So a finding pulled in by a few roots shows one name in the detail panel but a count in the column. If you feel like lining those up - detail row listing all roots, or a "+N more" - great. If not, it's a fine follow-up.

Thanks for the quick turnaround.

[sonukapoor]

One more before this lands: renderFindingRow is shared with the multi-folder HTML report (multi-folder-html-reporter.ts), which keeps its own 6-column table header. Once this PR adds the Root <td>, that table ends up with 7 cells under 6 headers and the columns shift. Could you add the Root <th> there too and bump that folder table's colspans (the empty row and the no-results row are colspan="6")? That keeps the multi-folder report aligned and gives it the Root column for parity.

Heads-up that PR #901 also touches that file, so this is cleanest to do once #901 lands - I'll ping you when it does.