[Feature] microsoft.flux: allow overriding AZURE_AUTHORITY_HOST / Entra cloud for Flux controllers

## **Is your feature request related to a problem? Please describe.**

We run AKS in Azure China and need Flux to reconcile from a Git repository in Azure DevOps, which
exists only in global Azure and is backed by a global Entra tenant. We want the secretless workload-identity
model (`GitRepository`, `.spec.provider: azure`), not a stored PAT.

The federation itself works: a federated credential on a global tenant managed identity accepts the
cluster's `.cn` OIDC issuer, and Azure DevOps accepts the resulting token (verified:
`_apis/profile/profiles/me` returns HTTP 200 from a Pod in the China cluster).

What we cannot do is tell `source-controller` to authenticate at the global authority. Flux's Azure
provider never sets `ClientOptions.Cloud`, so `azidentity` falls back to `AZURE_AUTHORITY_HOST`, which the AKS
workload identity webhook injects cluster-wide as `https://login.chinacloudapi.cn/`. That value is not in the
`source-controller` Deployment spec (it is injected at Pod admission), and `microsoft.flux` exposes settings
for which identity the controllers use, but not which Entra cloud they authenticate against.

A setup that works at every other layer is blocked by one environment variable we have no supported way to
set, and we have to give up Git as the source for this cluster because of it.

## **Describe the solution you'd like**

Either of:

```
workloadIdentity.azureAuthorityHost=https://login.microsoftonline.com/
source-controller.extraEnv.AZURE_AUTHORITY_HOST=https://login.microsoftonline.com/
```

The generic `extraEnv` form would also address #3273.

This should be a passthrough, not a webhook change. We confirmed that an `AZURE_AUTHORITY_HOST` already
present in a Pod spec is respected: the workload identity webhook does not overwrite an existing value.

## **Describe alternatives you've considered**

- **Object-level workload identity** (`.spec.serviceAccountName` on `GitRepository`) selects tenant and
client ID, not the cloud. There is no per-object authority field, and the feature gate is not exposed
anyway.
- **`kubectl set env` on the Deployment** works, but is reverted: the Deployment is Helm-managed with
`autoUpgradeMinorVersion` enabled. A delivery layer that silently stops reconciling after an extension
upgrade is not acceptable.
- **Our own `MutatingWebhookConfiguration`** survives Helm reconciliation, but puts our webhook in the
admission path of the delivery layer: `failurePolicy: Fail` stops `source-controller` starting when it is
down, and `Ignore` lets it start with the wrong authority and silently stop reconciling.
- **A stored PAT** abandons the secretless model, and Azure DevOps has no service PATs, so the cluster would
authenticate as a named user.
- **`OCIRepository` from an Azure China registry** It works, but this cluster no longer reads Git.

## **Additional context**

Azure China / China North 2 · Kubernetes v1.35.6 · `microsoft.flux` `1.24.1` with
`autoUpgradeMinorVersion: true` · `source-controller:v1.7.4-23` · OIDC issuer and workload identity enabled.

Related: **#4243** added the workload-identity settings but not the authority host, and notes that unmanaged
Flux can be patched where the extension cannot. **#3273** asks for customisation of extension-managed
controllers. **#5121** is the same divergence between ServiceAccount config and injected controller env, for
tenant rather than cloud.

The Azure China Flux tutorial documents `login.chinacloudapi.cn` for the extension agents and gives generic
Azure DevOps workload-identity instructions on the same page, with nothing bridging the two, so following the
documented configuration leads straight to the wrong authority.