chore: fix UFM transitive upgrades being marked as directly upgradable

[CatalinSnyk]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages
  are release-note ready, emphasizing
  what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

In certain cases the Remediation Summary from the UFM Presenter would treat transitive dependency upgrades as directly upgradable. This would results in incorrect upgrade advice (e.g. Upgrade from x@1.2.3 to x@1.2.3 - since the actual upgrade would be inside for a nested dependency).

Where should the reviewer start?

• GAF PR

How should this be manually tested?

• Running an OSS against the CLI repository with --reachability enabled should show some different results in terms of issues reported as directly upgradable. The changes should also align more the UFM remediation output to the legacy CLI output (can be teste with OSS scans with/without reachability enabled).

What's the product update that needs to be communicated to CLI users?

None.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.