Azure Logs: expose managed identity and workload identity federation auth options in the events (v2) policy template

### Integration Name

Azure Logs [packages/azure]

### Dataset Name

azure.events

### Integration Version

1.37.0

### Agent Version

9.4.3

### OS Version and Architecture

Elastic Agent 9.4.3 container (ECK-managed) on GKE, Linux x86_64

### User Goal

Configure the Azure Logs (v2) integration to consume from Event Hub with no shared secrets: Entra RBAC (`Azure Event Hubs Data Receiver` / `Storage Blob Data Contributor`) instead of SAS connection strings and storage account keys. On Azure-hosted agents that means `managed_identity`; for agents running outside Azure (GKE/EKS/on-prem Kubernetes) it means [workload identity federation](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation), where a federated credential on an App Registration trusts the cluster's OIDC issuer and the pod's projected token is exchanged for Entra tokens.

### Existing Features

The events policy template exposes `auth_type: connection_string` (SAS + storage key) or `client_secret` only. The underlying filebeat `azure-eventhub` input already supports `managed_identity`, but the template does not surface it, so Fleet-managed policies cannot use it (standalone users can hand-write it, which is how we run today). Workload identity federation is not supported at the input level at all; we filed elastic/beats#51992 for that. `client_secret` gets close (RBAC rather than SAS) but still leaves a rotatable secret in the policy.

### What did you see?

Not an error; a configuration gap: `packages/azure/data_stream/events/agent/stream/stream.yml.hbs` renders only `auth_type`/`connection_string`/`eventhub_namespace`/`tenant_id`/`client_id`/`client_secret`, and the manifest's `auth_type` options are Connection String and Client Secret. No `managed_identity` option, no federated/workload-identity option.

### Anything else?

Two asks, sequenced:

1. Surface the input's existing `managed_identity` support in the events (and ideally eventhub) policy templates now.
2. Once elastic/beats#51992 lands (`DefaultAzureCredential`/`WorkloadIdentityCredential` support in the input), expose that as well.

Our current workaround for non-Azure Kubernetes is a sidecar emulating the App Service managed-identity endpoint, which works but is an unsupported moving part we would like to delete.

Start with packages/azure/data_stream/events/agent/stream/stream.yml.hbs and the events policy manifest, comparing the existing auth_type options with the azure-eventhub input's managed_identity support. Expose managed_identity in the events template and its manifest, and check whether the eventhub template is in scope. Treat workload identity federation as dependent on elastic/beats#51992 rather than implementing it here.

Written by the indexing model from the issue text.