[BUG] Microsoft.Consumption/usageDetails does not return entries with multiple tags when a tag is included in the filter

### API Spec link

https://github.com/Azure/azure-rest-api-specs/blob/main/specification/consumption/resource-manager/Microsoft.Consumption/stable/2023-11-01/consumption.json

### API Spec version

2023-11-01

### Describe the bug

```
https://management.azure.com/subscriptions/{subscription}/providers/Microsoft.Consumption/usageDetails?api-version=2023-11-01&%24filter=tags%20eq%20%27dev%3Atools%27
```
Will return entries for a resource with `"tags": {"dev": "tools"}`
But it will not return entries for a resource with `"tags": {"dev": "tools", "foo": "bar"}`

### Expected behavior

Entries are returned for all resources matching the tag supplied in the filter, even if they have additional other tags.

### Actual behavior

Entries are not returned for resources with additional tags beyond just the one supplied in the filter.

### Reproduction Steps

**1. Create two resources with the given tags:**
Resource One:
```
"tags": {
"dev": "tools"
}
```
Resource Two:
```
"tags": {
"dev": "tools",
"foo": "bar"
}
```

**2. Attempt to get usageDetails filtering by tag:**
```
GET https://management.azure.com/subscriptions/{subscription}/providers/Microsoft.Consumption/usageDetails?api-version=2023-11-01&%24filter=tags%20eq%20%27dev%3Atools%27
```

**3. Observe that only one resource is returned**
👀

### Environment

Reproduced with:
* `azure-mgmt-consumption==10.0.0` with API versions `2023-05-01` and `2023-11-01` on Python 3.9.19
* [Azure Consumption rest API](https://learn.microsoft.com/en-us/rest/api/consumption/usage-details/list?view=rest-consumption-2023-05-01)'s "try it now" feature with API versions `2023-05-01` and `2023-11-01`

Start with specification/consumption/resource-manager/Microsoft.Consumption/stable/2023-11-01/consumption.json and inspect the Usage Details list operation and its $filter definition. Compare the documented behavior with the supplied requests and reproduction, then determine whether the specification can represent the expected matching of resources with additional tags. Done means the ownership and required specification change are clearly established.

Written by the indexing model from the issue text.