Add issue get command for FoD and SSC

[jmadhur87]

Added issue get command for both SSC and FoD to fetch a single issue by ID, avoiding full list + client-side filtering.
Supports optional --embed to include additional issue details.

fcli fod issue get
fcli ssc issue get

feat: Add get command for fcli ssc issue and fcli fod issue(#974 )

[Copilot]

Pull request overview

Adds new get subcommands to the ssc issue and fod issue command groups to retrieve a single issue/vulnerability by identifier, supporting optional embedded data and avoiding manual client-side filtering workflows.

Changes:

• Added fcli ssc issue get <id> --av <appversion> command and supporting i18n/table output definitions.
• Added fcli fod issue get <id|vulnId> --rel <release> command with i18n updates and command registration.
• Refactored SSC issue option message keys so --embed/--include descriptions can be shared beyond the list command.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
fcli-core/fcli-ssc/src/main/resources/com/fortify/cli/ssc/i18n/SSCMessages.properties	Adds SSC issue-get help + table defaults; renames embed/include message keys for reuse.
fcli-core/fcli-ssc/src/main/java/com/fortify/cli/ssc/issue/cli/mixin/SSCIssueIncludeMixin.java	Updates description key to new shared SSC issue include message key.
fcli-core/fcli-ssc/src/main/java/com/fortify/cli/ssc/issue/cli/cmd/SSCIssueGetCommand.java	New SSC leaf command to fetch a single issue for an app version.
fcli-core/fcli-ssc/src/main/java/com/fortify/cli/ssc/issue/cli/cmd/SSCIssueCommands.java	Registers SSCIssueGetCommand under ssc issue.
fcli-core/fcli-fod/src/main/resources/com/fortify/cli/fod/i18n/FoDMessages.properties	Adds FoD issue-get help text keys.
fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/issue/cli/cmd/FoDIssueGetCommand.java	New FoD leaf command to fetch a single vulnerability for a release.
fcli-core/fcli-fod/src/main/java/com/fortify/cli/fod/issue/cli/cmd/FoDIssueCommands.java	Registers FoDIssueGetCommand under fod issue.

[rsenden]

Apart from the individual comments on implementation details, we need to decide on what id's we should support, which is a tradeoff between fcli consistency vs usability.

For (almost) all other get commands in fcli, we just accept a single type of id, which corresponds to the id expected by the corresponding REST endpoint. This is what you've implemented for SSC, and would simplify the FoD implementation.

Also, we want to ensure consistency between issue get and issue update commands; these should accept the same type(s) of id('s). I think both FoD and SSC issue update commands currently only accept a single type of id (id for SSC, vulnId for FoD), so we should have the issue get commands accept those same types of id's only.

Having said that, for future consideration, we might want to consider deviating from this approach given that issues have multiple id's (id, issue instance id, and for FoD, vulnId).

For example, although users can see the SSC issue id in the output of the issue list command, I don't think this id is visible anywhere in the SSC UI. So, if users view an issue in SSC and then want to work on this issue in fcli (through issue get or issue update commands), they need to somehow figure out the issue id. Even SSC itself uses issueInstanceId filter instead of passing the issue id when opening the details for a given issue in a different browser window.

We can leave support for multiple types of id's as a future enhancement, although we need to think about the potential impact on command structure, for example whether we should have explicit options instead of a positional parameter (but that's inconsistent with other fcli get commands), to be able to differentiate between --id and --instance-id for example if we can't automatically determine the type of id being queried by the user. Alternatively, we can just try passing the given id through multiple REST queries on different fields (like you're more or less doing for FoD now, but not optimal from performance perspective), or support an optional prefix for the positional parameter, i.e., fcli ssc issue get instance-id:... vs fcli ssc issue get id:....

Somewhat related, for the issue update commands, I can imagine having a generic query option, i.e., update all issues that match a given query to perform bulk update, for example updating all issues in SQL Injection category, but again that's a potential future enhancement.

To summarize, maybe best to just have the issue get commands accept the same type of id as accepted by the issue update command for now, and raising an enhancement request for supporting additional id types on the issue get and issue update commands (again, these should be consistent as to what id types they support, likely through some shared helper class or resolver mixin), and another enhancement request for adding query support on the issue update command (maybe such an ER already exists though).