Microsoft.Cdn/profiles/secrets works with FrontDoor profile but not CDN

**Bicep version**
0.27.1

**Describe the bug**
Deploying a `Microsoft.Cdn/profiles/secrets@2024-02-01` resource against a `Microsoft.Cdn/profiles@2024-02-01` with SKU `Standard_AzureFrontDoor` (or `Premium_AzureFrontDoor`) works, but fails with "That action isn't valid on this profile" when the SKU is `Standard_Microsoft`.

**To Reproduce**

Assuming a Key Vault has been previously created, that it contains a certificate, and that the FrontDoor/CDN application has been granted access to it:

```bicep
param profileName string
param keyVaultName string
param keyVaultSecretName string

resource profile 'Microsoft.Cdn/profiles@2024-02-01' = {
name: profileName
location: 'global'
sku: { name: 'Standard_Microsoft' }
}

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
name: keyVaultName

resource secret 'secrets' existing = {
name: keyVaultSecretName
}
}

resource profileSecret 'Microsoft.Cdn/profiles/secrets@2024-02-01' = {
parent: profile
name: '${keyVaultName}-${keyVaultSecretName}-latest'
properties: {
parameters: {
secretSource: {
id: keyVault::secret.id
}
useLatestVersion: true
type: 'CustomerCertificate'
}
}
}
```

**Additional context**
This was reported over 2 years ago under #5567 but the "solution" is a workaround at best and not an actual solution.

Start by reproducing the supplied Bicep deployment with Standard_Microsoft and compare it with the working FrontDoor SKUs. Then inspect the repository's definitions for Microsoft.Cdn/profiles/secrets@2024-02-01; the issue names no file or test, so completion requires establishing whether the type definitions can represent the reported CDN behavior and adding appropriate coverage if so.

Written by the indexing model from the issue text.