Add a365 network gsa enable|disable|status

[Lala Sushant Srivastava (lasrivas)]

Adds a365 network gsa enable, disable, and status, so a tenant admin can turn Global Secure Access on or off for the Agent 365 environment.

Global Secure Access is a per-environment Power Platform setting, and Agent 365 does not publish the id of the managed environment it provisions, so the admin surfaces that take an environment id cannot reach it. The platform resolves the environment and applies the change; these commands carry no environment identifier at all.

Depends on the platform routes in bic/MCP-Platform#3686.

Stacked on #494 (a365 network vnet), which it bases on for NetworkCommand.cs. Merge that one first.

Summary

• Services/GsaService.cs + IGsaService.cs — calls /agents/gsa/{enable,disable,status}; correlation id, typed error bodies, a wall-clock convergence wait, and tenant-targeted authentication resolved from IAzureCliService.
• Models/GsaModels.cs — GsaStatusResponse, GsaErrorResponse.
• Commands/NetworkCommand.cs — a gsa subcommand tree beside vnet, plus ReportGsaAsync as the testable seam holding the wait-and-exit-code logic.
• Program.cs — DI registration and the new CreateCommand argument.
• docs/commands/network-gsa.md, a docs/commands/README.md row, and a CHANGELOG entry.
• Tests: Services/GsaServiceTests.cs and GSA cases in Commands/NetworkCommandTests.cs.

Non-obvious decisions

Tokens are requested for the tenant of the current az login, not just a login hint. A hint alone leaves the authority at common, and the Windows broker then ignores the hint and returns whichever account Windows prefers — silently, since the UPN mismatch is only logged at Debug. For a tenant-wide setting that means applying the change to the wrong tenant. Both the tenant and the user come from a single az account show via IAzureCliService, the same source vnet link already uses, rather than a --tenant-id option the caller would have to keep in sync with their az context. Passing the tenant also arms the mismatch self-heal already present in AuthenticationService, which is inert while tenantId is null. No az login now fails with a clear message instead of guessing.

status takes no --operation-id, unlike vnet status. Power Platform applies the change asynchronously but issues no operation id for it, so there is no handle to poll — the CLI converges by re-reading the setting instead.

NotConfigured is reported distinctly from Disabled. A tenant that has never set the value has not turned it off, and the distinction changes what an admin should do next.

A pending change exits 0. The platform accepted it and the environment is catching up; a non-zero exit would break scripts that chain on success. --wait is how a caller blocks on convergence.

409 gets its own message. A governing Power Platform policy owns the setting, and retrying cannot fix it, so the CLI says so rather than letting it read as transient.

Testing

Full CLI suite: 2120 passed, 0 failed, 12 skipped.

End to end against a real tenant, with the platform running locally on feature/gsa-environment-setting: status → Disabled, enable --wait → Enabled, status → Enabled, enable again → Enabled (no-op), disable --wait → Disabled, status → Disabled, disable again → Disabled (no-op). The environment was left in its original Disabled state.

[github-actions]

⚠️ Deprecation Warning: The deny-licenses option is deprecated for possible removal in the next major release. For more information, see issue 997.

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.