`RecoveryServices` Site Recovery Replicated VM Temporary Disk

Hi team, we found there is a temporary disk called `ms-asr-` created when creating the VM replication. This disk is then deleted automatically during the creation. However, its entry remains in the resource group list for some time (more than half an hour, could be longer), and the Get API of the disk itself returns `404 NotFound`. This causes failure in Terraform 3.0 when cleaning up the setup because Terraform 3.0 by default requires the resource group to be clean when deleting it.
Since the disk is already "deleted" which returns `404`, I think there is a cache mismatch in the resource list of the resource group. Although the temp disk entry in the resource list will be deleted automatically finally, it would be great if the resource list could be consistent when the creation is done.

Doc link: https://docs.microsoft.com/en-us/azure/site-recovery/azure-to-azure-quickstart
Swagger link: https://github.com/Azure/azure-rest-api-specs/blob/11830d3ce01db4f39a41dc37a86075b125c87fdc/specification/recoveryservicessiterecovery/resource-manager/Microsoft.RecoveryServices/stable/2021-10-01/service.json#L2678

API test I've made after the VM replication is created (state is `Protected`):
```
// Get Disk returns 404
GET https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/YICMA-RECOVERY-PRIMARY/providers/Microsoft.Compute/disks/ms-asr-73dfbb06-18f0-5c09-b24d-a9f9568d2c7b?api-version=2021-08-01
{
"error": {
"code": "NotFound",
"message": "Disk ms-asr-73dfbb06-18f0-5c09-b24d-a9f9568d2c7b is not found."
}
}

// Resource list of the resource group still has it
GET https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/yicma-recovery-primary/resources?api-version=2022-01-01&$filter=substringof(name, 'ms-asr')
{
"value": [
{
"id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/YICMA-RECOVERY-PRIMARY/providers/Microsoft.Compute/disks/ms-asr-73dfbb06-18f0-5c09-b24d-a9f9568d2c7b",
"name": "ms-asr-73dfbb06-18f0-5c09-b24d-a9f9568d2c7b",
"type": "Microsoft.Compute/disks",
"sku": {
"name": "Standard_LRS",
"tier": "Standard"
},
"location": "northeurope",
"tags": {
"azsecpack": "nonprod",
"platformsettings.host_environment.service.platform_optedin_for_rootcerts": "true",
"Created": "by ASR Gateway Service on 5/10/2022 3:17:11 AM.",
"ms-asr-snapshot-id": "c4a202f3-b05c-4821-9841-463bd8f59150",
"ms-asr-source-disk": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/yicma-recovery-primary/providers/microsoft.compute/disks/yicma-src-vm_osdisk_1_2ece226880e04b9eb308b7e6ccf6fb85"
}
}
]
}
```

Start with the Recovery Services specification in service.json near line 2678, then compare the disk GET response with the resource-group list response shown in the report. Reproduce the sequence after replication reaches Protected and determine whether the API specification captures the observed behavior. Done means the inconsistency is resolved or the expected behavior is explicitly represented in the specification.

Written by the indexing model from the issue text.