[azure_metrics]: monitor metricset: single unsupported resource type in resource group degrades entire unit, blocking collection for correctly-configured resource types

### Integration Name

Azure Resource Metrics [packages/azure_metrics]

### Dataset Name

_No response_

### Integration Version

1.14.0

### Agent Version

9.4.4

### Agent Output Type

elasticsearch

### Elasticsearch Version

9.4.4

### OS Version and Architecture

Architecture: x86_64, Red Hat Enterprise Linux (running in AKS as a `hostNetwork` DaemonSet)

### Software/API Version

_No response_

### Error Message

{"log.level":"warn","message":"Unit state changed azure/metrics-default-azure/metrics-monitor- (HEALTHY->DEGRADED): Recoverable: Error fetching data for metricset azure.monitor: GET https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Insights/activityLogAlerts//providers/Microsoft.Insights/metricDefinitions\n--------------------------------------------------------------------------------\nRESPONSE 400: 400 Bad Request\nERROR CODE: BadRequest\n--------------------------------------------------------------------------------\n{\n \"code\": \"BadRequest\",\n \"message\": \"Microsoft.Insights/activityLogAlerts is not a supported platform metric namespace, supported ones are Microsoft.AppPlatform/Spring,...,Microsoft.KeyVault/vaults,...,Microsoft.Web/sites,... [full supported list truncated for brevity]\"\n}"}

### Event Original

_No response_

### What did you do?

Configured the monitor-azure/metrics input's azure.monitor stream with a resources YAML explicitly listing 27 valid, metric-capable resource_type values (e.g. microsoft.keyvault/vaults, microsoft.web/sites, microsoft.network/applicationgateways, microsoft.network/expressroutecircuits, etc.), each with metrics: [{name: ["*"]}], deployed via the standard Fleet integration policy. The target resource groups in scope also contain typical companion monitoring/alerting resources (Action Groups, Workbooks, Activity Log Alerts) alongside the intended monitored resources.

### What did you see?

The metrics-azure.monitor-* index contains only error documents referencing unsupported resource types (Action Groups, Workbooks, Activity Log Alerts) — zero successful metric documents exist for any of the 27 explicitly-configured resource_type entries, despite the live Fleet policy configuration being verified to exactly match intent. A single 400 BadRequest from an unsupported/incompatible resource type degrades the entire azure/metrics-monitor unit (HEALTHY → DEGRADED).
Other azure/metrics policy templates (compute_vm, storage_account, database_account) in the same integration policy, using identical client_id/client_secret/tenant_id credentials, successfully collect metrics.

### What did you expect to see?

The monitor metricset should skip/log a warning for any discovered resource whose type doesn't support Azure Monitor platform metrics, and continue successfully collecting metrics for the remaining, correctly-configured resource types in the same cycle — not degrade the entire unit and block collection for all configured types.

### Anything else?

It appears the monitor metricset's resource discovery is not strictly limited to the configured resource_type list — it also encounters unrelated resources within the same resource group scope (Action Groups, Workbooks, Activity Log Alerts), which are extremely common companion resources in any production monitoring/alerting setup. This makes the bug likely to affect a large proportion of real-world monitor stream deployments, not just this specific configuration.

Start in packages/azure_metrics, focusing on the monitor-azure/metrics input and its azure.monitor stream. Reproduce with a resources YAML containing valid metric-capable types alongside Action Groups, Workbooks, or Activity Log Alerts; done means unsupported resources are skipped or warned about while valid resource types continue producing metric documents without degrading the unit.

Written by the indexing model from the issue text.