feat: add a group filter to project list

[NickJosevski]

Adds an optional group filter to octopus project list:

octopus project list --group 'Default Project Group'
octopus project ls -g ProjectGroups-1

Why

There was no way to narrow project list to a single project group. The nearest thing was project-group view, which shows group metadata with the projects nested inside it — fine for a look, awkward when the projects are what you actually want.

This is the alternative shape proposed on #388, which added a project-group projects list command instead. Putting the filter on project list is more discoverable (people looking for projects reach for project list), matches the -g/--group flag project create and project clone already use, and avoids a three-level project-group projects list whose middle noun would exist to hold a single verb. Credit for spotting the gap goes to @nate-christensen.

Behaviour

• No flag: unchanged — Projects.GetAll(), same output and columns as before.
• With a group: resolved by name or ID, then listed from that group's own Projects link, which the server pages for us rather than us fetching every project and discarding most of them. (The projects collection has no projectGroupId filter, so this is the available route either way.)
• Unknown group: cannot find a project group with name or ID of 'X', matching the wording in the delete commands, rather than the SDK's bare cannot find the item. Other lookup errors pass through untouched.

The selection logic sits in a small getProjects function taking callbacks, so it is unit-testable without a factory mock — five tests cover no-filter, filter, unknown group, nil group and unrelated-error paths.

Verification

Build, vet, gofmt and tests clean. Against a local instance: created a throwaway group and project, confirmed the filter discriminates by both name and ID (16 projects total, 1 in the temp group, 15 in the default), then removed them. Also diffed the raw field sets returned by /projects and /projectgroups/X/projects — identical, ProjectTags included, so the TAGS column behaves the same on either path.

Draft because

Raised as a draft pending a decision on #388 — if we go this way, that PR should be closed in favour of this one.

🤖 Generated with Claude Code