[BUG] Publisher sends GraphQL schema to service-level API path instead of workspace path

[michelversluijs]

Release version

APIOps Toolkit for Azure APIM v7.0.2

Describe the bug

When publishing a GraphQL API that belongs to a workspace, the publisher constructs the wrong URI for the GraphQL schema PUT. It targets the service-level API schemas endpoint instead of the workspace-scoped one, causing a 403 AuthorizationFailed error.

The failing request:

PUT .../service/{serviceName}/apis/{apiId}/schemas/graphql

Expected request:

PUT .../service/{serviceName}/workspaces/{workspaceId}/apis/{apiId}/schemas/graphql

Expected behavior

Publisher successfully PUTs the GraphQL schema to workspaces/{workspaceId}/apis/{apiId}/schemas/graphql and the API deploys without error.

Actual behavior

Publisher fails with HTTP 403:

System.Net.Http.HttpRequestException: HTTP request to URI
https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/
Microsoft.ApiManagement/service/{serviceName}/apis/{apiId}/schemas/graphql
?api-version=2024-05-01 failed with status code 403.
Content is '{"error":{"code":"AuthorizationFailed","message":"The client '...'
does not have authorization to perform action
'Microsoft.ApiManagement/service/apis/schemas/write' over scope
'.../service/{serviceName}/apis/{apiId}/schemas/graphql'
or the scope is invalid."}}'.

Reproduction Steps

1. Create a GraphQL API inside an APIM workspace.
2. Run the extractor — specification.graphql is written correctly (extractor is unaffected).
3. Run the publisher against a different environment — it fails with 403.

[github-actions]

  Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
  Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.