Set-PowerBIWorkspace unexpectedly throws HttpOperationException (Unauthorized)

I noticed unexpected behavior between the Get and Set commands PowerBI workspaces:

1. Authenticate with a service principal via Connect-PowerBIServiceAccount using ClientSecret & ClientID credentials
2. Run Get-PowerBIWorkspace (should successfully show a list of workspaces to which the SP has access)
3. Run Set-PowerBIWorkspace -WorkspaceId $workspaceId -CapacityId $capacityId -Scope Organization
4. Receive HttpOperationException: Unauthorized.

This doesn't appear to be a permissions issue as making a REST call via Invoke-PowerBIRestMethod to the https://api.powerbi.com/v1.0/myorg/groups/$GroupId/AssignToCapacity endpoint works fine (the SP is a capacity admin). Additionally, the error is a 401 not a 403 so it appears to be authentication related rather than authorization

After sniffing traffic with Fiddler, it appears this command is calling the https://api.powerbi.com/v1.0/myorg/admin/capacities/AssignWorkspaces endpoint which does not appear in the API documentation for capacity.

Documentation does appear for this endpoint regarding the Power BI Admin REST API. However, since this commandlet is part of MicrosoftPowerBIMgmt.Workspaces rather than MicrosoftPowerBIMgmt.Admin I would expect it to use non-admin endpoints like the one referenced above such that it can accomplish the same task with more limited permissions, as well as keeping these commandlets in line with the principle of least-surprise for other devs.

TLDR: Workspace-level capacity setting functionality should not unnecessarily rely on admin endpoints when group/workspace-specific capacity assignment endpoints exists, unless I'm missing something.

Start at the Set-PowerBIWorkspace implementation and trace the request made for -Scope Organization. Compare it with the documented AssignWorkspaces and AssignToCapacity endpoints, using the reported service-principal authentication flow as the reproduction case. Done means the command succeeds with the required non-admin workspace-level permissions and no longer unexpectedly returns 401.