Feature request: optional project-role / group visibility on `jira issue comment add` (REST v3)

[jordanlgraham]

Discussion for this feature request is here.

Is your feature request related to a problem? Please describe.

We run automation that posts Jira Cloud comments that must be restricted to a project role (e.g. Developers). Jira exposes this via POST /rest/api/3/issue/{issueIdOrKey}/comment with a visibility object (type: role or group, plus value). Right now jira issue comment add goes through AddIssueComment (pkg/jira/issue.go): REST v2, markdown → Jira wiki, and --internal via sd.public.comment. There is no way to set role or group visibility like the v3 API supports, so in our use case we have had to bypass the CLI and call the REST API directly.

Describe the solution you'd like

• Optional flags on jira issue comment add, for example:
  • --visibility-role <project-role-name> → { "type": "role", "value": "<name>" }
  • --visibility-group <group-name> → { "type": "group", "value": "<name>" }
• When visibility is set, use the REST v3 comment endpoint and a valid v3 body (e.g. ADF), aligned with Add comment.
• Default behavior unchanged when these flags are omitted.

Describe alternatives you've considered

• Keep posting comments with curl/scripts against v3 instead of using jira-cli (works but duplicates auth/config and misses jira-cli ergonomics).
• Rely on --internal / sd.public.comment only — that targets JSM-style internal comments, not arbitrary project role visibility on normal issues.

Additional context

• On Jira Cloud, identifier and value are mutually exclusive in visibility; use type + value only for role/group (including both caused HTTP 400 in our tests).
• Interaction with --internal should be defined explicitly (e.g. mutually exclusive flags or documented precedence).