AZFD0010 timezone diagnostic never fires on Linux Consumption apps hosted on Legion

### Summary

The `AZFD0010` diagnostic event that warns customers about the unsupported `TZ` / `WEBSITE_TIME_ZONE` app settings on Linux Consumption is **unreachable for Linux Consumption apps hosted on Legion**. The guard is scoped to the legacy Atlas/ACI hosting mode only, so after the Linux Consumption migration to Legion the warning silently stopped firing for the affected population.

Related: #9203 (the original bug), #9662 (the PR that added the diagnostic).

### Current behavior

`WebJobsScriptHostService.ValidateLinuxSKUConfiguration` is the only place `AZFD0010` is emitted:

https://github.com/Azure/azure-functions-host/blob/d3dd29e5b076bef2c28a334f95e572ca0f039b64/src/WebJobs.Script.WebHost/WebJobsScriptHostService.cs#L292-L307

### Why it can never fire on Legion

The two hosting-mode predicates in `EnvironmentExtensions` are **mutually exclusive by construction** on `LEGION_SERVICE_HOST`:

```csharp
public static bool IsLinuxConsumptionOnAtlas(this IEnvironment environment)
{
return !environment.IsAppService()
&& !string.IsNullOrEmpty(environment.GetEnvironmentVariable(ContainerName))
&& string.IsNullOrEmpty(environment.GetEnvironmentVariable(LegionServiceHost)); // must be EMPTY
}

public static bool IsConsumptionOnLegion(this IEnvironment environment)
{
return !environment.IsAppService()
&& (...)
&& !string.IsNullOrEmpty(environment.GetEnvironmentVariable(LegionServiceHost)); // must be NON-EMPTY
}
```

On Legion, `LEGION_SERVICE_HOST` is set, so `IsLinuxConsumptionOnAtlas()` returns `false` and the block is dead code.

### Impact

The `TZ` / `WEBSITE_TIME_ZONE` misconfiguration is **documented public behavior** with severe, non-obvious consequences. From [Timer trigger — NCRONTAB time zones](https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-timer#ncrontab-time-zones):

> `WEBSITE_TIME_ZONE` and `TZ` aren't currently supported when running on Linux in a Flex Consumption or Consumption plan. In this case, the setting `WEBSITE_TIME_ZONE` or `TZ` can create SSL-related issues and cause metrics to stop working for your app.

In practice the failure presents as:

```
Azure.RequestFailedException: The SSL connection could not be established, see inner exception.
---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Cryptography.CryptographicException: Error occurred during a cryptographic operation.
at Interop.Crypto.X509StoreSetVerifyTime(SafeX509StoreHandle ctx, DateTime verifyTime)
at System.Security.Cryptography.X509Certificates.OpenSslX509ChainProcessor.InitiateChain(...)
at System.Net.Security.SslStream.VerifyRemoteCertificate(...)
```

This breaks **all outbound HTTPS from the host process**, so:

- every singleton/timer listener fails to start (timer functions never execute at all)
- `SyncTriggers` fails
- Application Insights receives no telemetry
- the `azure.functions.webjobs.storage` health check reports `Unhealthy` with the generic `"Unable to access AzureWebJobsStorage"` description

The failure is fully deterministic — every host instance for an affected app is impacted, and restarts do not help.

Because the symptom surfaces as a **storage/TLS error** rather than a configuration error, and because the diagnostic that would name the actual cause never fires, affected customers and support engineers reasonably conclude the storage account or networking is at fault. This has produced multi-week investigations chasing storage keys, TLS settings, firewall rules, and DNS — none of which are the cause. The diagnostic exists precisely to short-circuit that, and it is not reaching the affected population.

Start with ValidateLinuxSKUConfiguration in src/WebJobs.Script.WebHost/WebJobsScriptHostService.cs and the hosting-mode predicates in EnvironmentExtensions. Trace how AZFD0010 is gated, then verify that Linux Consumption on Legion reaches the diagnostic while the existing Atlas behavior remains correct; related issues #9203 and #9662 provide historical context.

Written by the indexing model from the issue text.