ManagedCluster GET at api-version 2026-06-01 returns containerInsights.logAnalyticsWorkspaceResourceId as empty string when Container Insights is disabled, breaking generated SDK clients

### Describe the bug

From api-version `2026-06-01`, `GET Microsoft.ContainerService/managedClusters` returns the `azureMonitorProfile.containerInsights` block for clusters where Container Insights has never been enabled, with an **empty string** in `logAnalyticsWorkspaceResourceId`:

```json
"azureMonitorProfile": {
"containerInsights": {
"enabled": false,
"logAnalyticsWorkspaceResourceId": ""
}
}
```

Every stable api-version up to and including `2026-05-01` omits the `containerInsights` block entirely for the same cluster.

The API specification declares this field as an ARM resource id ([`managedClusters.json` for 2026-06-01](https://github.com/Azure/azure-rest-api-specs/blob/main/specification/containerservice/resource-manager/Microsoft.ContainerService/aks/stable/2026-06-01/managedClusters.json), `ManagedClusterAzureMonitorProfileContainerInsights`):

```json
"logAnalyticsWorkspaceResourceId": {
"type": "string",
"format": "arm-id",
...
}
```

An empty string is not a valid ARM resource id, so responses at this api-version violate the declared contract for any cluster with Container Insights disabled.

### Impact

Generated SDK clients trust the `arm-id` format. The .NET SDK (`Azure.ResourceManager.ContainerService` 1.7.0, the first release targeting 2026-06-01) deserializes the field with:

```csharp
logAnalyticsWorkspaceResourceId = new ResourceIdentifier(prop.Value.GetString());
```

`ResourceIdentifier` rejects empty strings, so **every full `GET` of an affected ManagedCluster throws** `ArgumentException: Value cannot be an empty string. (Parameter 'resourceId')` during deserialization — regardless of which property the caller wanted. The SDK team closes this class of report as service-side (Azure/azure-sdk-for-net#52911: "this issue is related to the service side and not the SDK side"), and the sibling defect in NetApp (Azure/azure-sdk-for-net#51803) has been open since August 2025, which is why this is filed against the RP rather than the SDK.

### To Reproduce

On any AKS cluster where Container Insights has never been enabled:

```bash
az rest --url "https://management.azure.com/subscriptions/<sub>/resourceGroups//providers/Microsoft.ContainerService/managedClusters/?api-version=2026-06-01" \
--query "properties.azureMonitorProfile.containerInsights"
# => { "enabled": false, "logAnalyticsWorkspaceResourceId": "" }</sub>

az rest --url "https://management.azure.com/subscriptions/<sub>/resourceGroups//providers/Microsoft.ContainerService/managedClusters/?api-version=2026-05-01" \
--query "properties.azureMonitorProfile.containerInsights"
# => null (block omitted)
```</sub>

Or with the .NET SDK: `Azure.ResourceManager.ContainerService` 1.7.0, `GetContainerServiceManagedClusterResource(id).GetAsync()` → throws the `ArgumentException` above. The same call succeeds when the client pins the wire version via `ArmClientOptions.SetApiVersion(ContainerServiceManagedClusterResource.ResourceType, "2026-05-01")`, which is the workaround we are shipping.

### Expected behavior

When Container Insights is disabled and no workspace is associated, either omit `logAnalyticsWorkspaceResourceId` (as every api-version through 2026-05-01 does) or return `null` — never `""` in a field declared `format: arm-id`.

### Environment

- Region: North Europe
- api-versions compared: 2026-05-01 (correct) vs 2026-06-01 (regressed)
- Client: Azure.ResourceManager.ContainerService 1.7.0 (.NET), but any strict `arm-id` consumer is affected