Microsoft.RecoveryServices - confusing/incorrect error message

### API Spec link

https://github.com/Azure/azure-rest-api-specs/blob/main/specification/recoveryservicesbackup/resource-manager/Microsoft.RecoveryServices

### API Spec version

2023-02-01

### Question/Query

The API returns a confusing/incorrect error message when attempting to set an existing backup item's `ProtectionState` to `BackupsSuspended`.

Error message:
```
{
"error": {
"code": "UserErrorOperationDeniedOnImmutableItem",
"message": "The Vault and Bakcup Item is in Immutable state where destructive operations are not supported. The Vault and Backup Item is immutable, hence operation is denied. Refer to the documentation to learn more: https://aka.ms/AB-ImmutableVaults-States "
}
}
```

The error message above seems to imply that this operation was denied because the vault was in an immutable state, which it was not, interestingly [enabling vault immutability](https://learn.microsoft.com/en-us/azure/backup/backup-azure-immutable-vault-how-to-manage?tabs=recovery-services-vault#enable-immutable-vault) and sending the request again responds with `HTTP 202` and subsequent `GET` requests show this was applied to the backup item.

I encountered it in API version `2023-02-01` however the behaviour seems to be the same in the latest stable version (`2024-10-01`)

Example Request

```
PUT https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.RecoveryServices/vaults//backupFabrics//protectionContainers//protectedItems/VM;?api-version=2023-02-01

{
"properties": {
"protectedItemType": "Microsoft.Compute/virtualMachines",
"protectionState": "BackupsSuspended",
"sourceResourceId": "/subscriptions//resourceGroups//providers/Microsoft.Compute/virtualMachines/"
}
}
```

### Environment

_No response_

Start with the linked Microsoft.RecoveryServices API specification for version 2023-02-01 and compare the protectedItems operation with version 2024-10-01. Reproduce the BackupsSuspended request and inspect the documented error behavior; done when the source of the misleading message is identified and the API specification or service ownership is clear.

Written by the indexing model from the issue text.