feat: Implement `azdo pipelines variable-group create` command

[tmeckel]

This issue tracks the implementation of the azdo pipelines variable-group create command.

Command Description

Create a variable group in the target project and optionally authorize it for pipelines. The Azure CLI command (az pipelines variable-group create) builds a VariableGroupParameters payload and, when requested, toggles authorization via set_authorize_resource (source). azdo should expose the same capability with clearer positional scope handling, structured output, and more complete coverage of the REST surface.

azdo Command Signature

azdo pipelines variable-group create [ORGANIZATION/]PROJECT/NAME [flags]

Arguments:

• [ORGANIZATION/]PROJECT/NAME (required): Project scope using the positional parsing pattern documented in ISSUE-TRIAGE.md. If the organization segment is omitted, fall back to the configured default or return an error when unavailable. NAME (required): Display name for the variable group.

Flags:

• --description, -d: Optional description string.
• --authorize, -A: Mark the variable group as authorized for all pipelines in the project after creation.
• --type: Variable group type (Generic by default, AzureKeyVault when Key Vault data is provided).
• --is-shared: Boolean toggle to mark the group as shared across projects.
• --project-reference <id>|<name>: Repeatable flag to seed VariableGroupProjectReferences.ProjectReference. The parameter can be used multiple times or used with comma separated values. It supports either the uuid of the project or it's name. If the name is specified the command must resolve the project id (UUID)
• --variable, -v key=value[;readOnly=true|false]: Repeatable flag for non-secret variables seeded at creation time. Reject duplicate keys (case-insensitive) and ensure readOnly maps to VariableValue.IsReadOnly.
• --secret name=value: Convenience wrapper for non-KeyVault secret variables (stored as IsSecret=true). Secret values must be supplied through environment or prompt flows; never echo in output.
• --keyvault-service-endpoint, --keyvault-name, --keyvault-secret secretName=kvSecret: Flags for Key Vault-managed groups. Reject mixing Key Vault provider data with --variable/--secret.
• --provider-data-json <path-or-inline>: Advanced escape hatch to pass raw provider data for future providers.
• JSON export flags from util.AddJSONFlags covering the show/update field set (id, name, type, description, isShared, authorized, variables, variableGroupProjectReferences, providerData, createdBy, createdOn, modifiedBy, modifiedOn).

Behavior

• Resolve scope, IO streams, and start a progress indicator immediately; stop it before printing output.
• Normalize variable/secret inputs into a map of taskagent.VariableValue (mask secrets in table output and omit values in JSON when IsSecret is true).
• For Key Vault flows, build an AzureKeyVaultVariableGroupProviderData payload and map each --keyvault-secret entry to VariableValue{IsSecret:true, Value:<secretName>}.
• Apply --project-reference into VariableGroupProjectReferences.ProjectReference (accept both GUID and name inputs; resolve GUID via Core client when project names are provided).
• Populate taskagent.VariableGroupParameters with Name, Description, Type, IsShared, Variables, ProviderData, and VariableGroupProjectReferences, then call client.AddVariableGroup.
• When --authorize is set, use the approvals-and-checks API (or equivalent helper) to mark the resource authorized. Surface an error if that step fails.
• Default table output via ctx.Printer("list") with columns such as ID, NAME, TYPE, AUTHORIZED, VARIABLE COUNT, DESCRIPTION. JSON export should reuse the show view struct for consistency.
• Emit debug logging for parsed scope, variable counts, provider decisions, and authorization paths (zap.L().Debug).

Command Wiring

• Implement the command in internal/cmd/pipelines/variablegroup/create/create.go with NewCmd(ctx util.CmdContext) *cobra.Command.
• Register it from internal/cmd/pipelines/variablegroup/variablegroup.go so azdo pipelines variable-group create is exposed.
• Regenerate documentation (make docs) after wiring.

SDK / Client Requirements

• Requires the Task Agent client (ClientFactory().TaskAgent(...)) for CRUD operations.
• Authorization toggling and Key Vault flows may require the Service Endpoint client and/or Approvals-and-Checks helpers. Confirm existing factories expose the needed clients; if any are missing, follow "Handling Missing Azure DevOps SDK Clients" in AGENTS.md (extend ClientFactory, run go mod tidy and go mod vendor, update scripts/generate_mocks.sh, and implement the factory method) before implementing command logic.

Tooling & Validation

• Format new Go files with gofmt/goimports.
• Run go build ./cmd/azdo/... to ensure the CLI compiles.
• Add/update hermetic tests using mocks (Task Agent client, optional Service Endpoint/Security interactions) and execute go test ./....

Testing

Table-driven unit tests under internal/cmd/pipelines/variablegroup/create/create_test.go covering:

1. Successful creation with description, variables, project references, and authorization.
2. Duplicate variable keys (case-insensitive) returning a validation error.
3. Missing organization default when only PROJECT is supplied.
4. Authorization failure surfacing an error without printing success output.
5. Key Vault provider data path (including rejection when mixed with --variable).
6. JSON export verifying serialized payload.

References

• Azure CLI implementation: variable_group_create
• Azure DevOps REST API 7.1: Add variable group
• Azure DevOps docs: Manage variable groups