fix(issue): keep --confidential and --iteration with --group

Description

glab issue list --group <group> --confidential and glab issue list --group <group> --iteration <id> send neither confidential nor iteration_id to the group issues API, so they list every issue of the group. glab incident list --group <group> --confidential goes through the same code and has the same gap (--iteration is offered for issues only). listRun sets Confidential and IterationID on the project list options (issuable_list.go#L270-271, #L291-292). Without --group those options go to ListProjectIssues as they are, but with --group they are converted by projectListIssueOptionsToGroup (#L499-526), which copies the other filters but not these two.

This MR copies Confidential and IterationID in projectListIssueOptionsToGroup. ListGroupIssuesOptions has both fields, and the group issues endpoint accepts both parameters. Nothing changes without --group.

The same two lines are already in !3256, where the gap came up in review, as part of a larger change that targets another branch. This MR lands just these two lines on main, with a test for the --group path. When !3256 is rebased onto main, the lines are already there and drop out of its diff without adding a conflict.

Related Issues

Closes #8614 (closed)

How has this been tested?

A new test in internal/commands/issuable/list/issuable_list_test.go, TestIssueList_groupPassesConfidentialAndIteration, runs issue list --group GROUP --confidential --iteration 9 against the mocked ListGroupIssues and checks that both options reach it. Without the change to issuable_list.go it fails with confidential filter dropped for group listing; with only Confidential copied it fails with iteration filter dropped for group listing; with the change it passes.

With Go 1.27.2 and golangci-lint 2.14.0: go test -race ./... passes, golangci-lint run reports 0 issues, golangci-lint fmt --diff, go run ./scripts/comment-overlap -threshold 1.0 -max-findings 0 ./cmd/... ./internal/... and make check-embed check-args are clean, and the commit message and the title pass commitlint with scripts/commit-lint/.commitlintrc.js.

End to end, I built glab from main and from this branch and ran glab issue list --group GROUP against a small stub of the group issues route, which logs every request and filters four issues on confidential and iteration_id the way the API does. With --confidential, --iteration 9 or both, the main build sent neither parameter and listed all four issues; this branch sent the parameters and listed only the matching ones. glab incident list --group GROUP --confidential behaved the same way: the main build sent no confidential and listed all four, and this branch sent confidential=true and listed the two confidential ones.

Test output without and with the change

Without the change to issuable_list.go:

    issuable_list_test.go:485:
        	Error Trace:	.../internal/commands/issuable/list/issuable_list_test.go:485
        	Error:      	Expected value not to be nil.
        	Messages:   	confidential filter dropped for group listing
--- FAIL: TestIssueList_groupPassesConfidentialAndIteration (0.00s)
FAIL	gitlab.com/gitlab-org/cli/internal/commands/issuable/list

With it:

--- PASS: TestIssueList_groupPassesConfidentialAndIteration (0.00s)
ok  	gitlab.com/gitlab-org/cli/internal/commands/issuable/list

Command: go test -count=1 ./internal/commands/issuable/list/ -run TestIssueList_groupPassesConfidentialAndIteration -v

End-to-end runs against the stub

The stub answers GET /api/v4/groups/:id/issues and GET /api/v4/projects/:id/issues with the same four issues, keeping only the confidential ones when the request carries confidential=true and only the ones in iteration 9 when it carries iteration_id=9, and logs every request.

### main, glab issue list --group GROUP --confidential --iteration 9
Showing 4 of 4 open issues in GROUP that match your search. (Page 1)

ID	Title	Labels	Created at
#1	Public issue, no iteration		about 12 days ago
#2	Confidential issue, no iteration		about 12 days ago
#3	Public issue in iteration 9		about 12 days ago
#4	Confidential issue in iteration 9		about 12 days ago

GET /api/v4/groups/GROUP/issues?in=title%2Cdescription&order_by=created_at&page=1&per_page=30&sort=desc&state=opened

### this branch, glab issue list --group GROUP --confidential --iteration 9
Showing 1 of 1 open issue in GROUP that match your search. (Page 1)

ID	Title	Labels	Created at
#4	Confidential issue in iteration 9		about 12 days ago

GET /api/v4/groups/GROUP/issues?confidential=true&in=title%2Cdescription&iteration_id=9&order_by=created_at&page=1&per_page=30&sort=desc&state=opened

### main, --group GROUP --confidential: 4 issues listed
GET /api/v4/groups/GROUP/issues?in=title%2Cdescription&order_by=created_at&page=1&per_page=30&sort=desc&state=opened

### this branch, --group GROUP --confidential: issues #2 and #4 listed
GET /api/v4/groups/GROUP/issues?confidential=true&in=title%2Cdescription&order_by=created_at&page=1&per_page=30&sort=desc&state=opened

### main, --group GROUP --iteration 9: 4 issues listed
GET /api/v4/groups/GROUP/issues?in=title%2Cdescription&order_by=created_at&page=1&per_page=30&sort=desc&state=opened

### this branch, --group GROUP --iteration 9: issues #3 and #4 listed
GET /api/v4/groups/GROUP/issues?in=title%2Cdescription&iteration_id=9&order_by=created_at&page=1&per_page=30&sort=desc&state=opened

### main and this branch, glab issue list -R OWNER/REPO --confidential --iteration 9: issue #4 listed
GET /api/v4/projects/OWNER%2FREPO/issues?confidential=true&in=title%2Cdescription&iteration_id=9&order_by=created_at&page=1&per_page=30&sort=desc&state=opened

### main, glab incident list --group GROUP --confidential: 4 listed
GET /api/v4/groups/GROUP/issues?in=title%2Cdescription&issue_type=incident&order_by=created_at&page=1&per_page=30&sort=desc&state=opened

### this branch, glab incident list --group GROUP --confidential: #2 and #4 listed
GET /api/v4/groups/GROUP/issues?confidential=true&in=title%2Cdescription&issue_type=incident&order_by=created_at&page=1&per_page=30&sort=desc&state=opened

The stub does not filter on issue_type, so the incident runs draw on the same four items as the issue runs.