Deploymentstack delete is not working correctly

### Describe the bug

I created a subscription level deployment with bicep and created a deployment stack.
After the stack was created, I added one new resource (in my case a new storageaccount) in one of the resource groups.
When the delete action of the deploymentstack is called, everything is removed, also the newly created storage account which is not part of the deploymentstack.

### Related command

az stack sub create --name "WW-TEST" --location "eastus" --template-file "./test.bicep" --deny-settings-mode "none" --debug --y

Creates everything according to the bicep templates. (Subscriptionlevel deployment with two subdeployments)
Added a storage account in one of the subscriptions with the Azure portal

az stack sub delete --name "WW-TEST" --delete-all --y

[storage.txt](https://github.com/Azure/azure-cli/files/12239564/storage.txt)
[test.txt](https://github.com/Azure/azure-cli/files/12239565/test.txt)

### Errors

Both resourcegroups are being removed even if there are a resources which are not part of the deploymentstack.

### Issue script & Debug output

[azstackcreate.txt](https://github.com/Azure/azure-cli/files/12239698/azstackcreate.txt)
[azstackdelete.txt](https://github.com/Azure/azure-cli/files/12239699/azstackdelete.txt)

### Expected behavior

Resources and Resourcegroups should not be deleted when at least one resource is not part of the deploymentstack.
This should not happen according to the documentation. The expected behavior should be that the resourcegroup and the resources remain which are not part of the deploymentstack.

### Environment Summary

azure-cli 2.51.0

core 2.51.0
telemetry 1.1.0

Dependencies:
msal 1.24.0b1
azure-mgmt-resource 23.1.0b2

Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\WernerWopienka\.azure\cliextensions'

Python (Windows) 3.10.10 (tags/v3.10.10:aad5f6a, Feb 7 2023, 17:05:00) [MSC v.1929 32 bit (Intel)]

Legal docs and information: aka.ms/AzureCliLegal

### Additional context

same behavior is happening with the powershell modules