az webapp create ignores siteConfigPropertiesDictionary from the selected App Service stack

# Describe the bug

`az webapp create --runtime` resolves the selected runtime but does not apply the stack-specific site configuration supplied by the App Service stacks API in `siteConfigPropertiesDictionary`.

The current observable failure is Windows Node 24. Its stack metadata includes:

```json
{
"siteConfigPropertiesDictionary": {
"use32BitWorkerProcess": false
}
}
```

Node 24 is 64-bit only, but an app created with `--runtime "NODE:24LTS"` has `use32BitWorkerProcess: true`. A Node 24 probe then fails with HTTP 500. Changing only this property to `false` allows the same probe to run successfully as Node 24 x64.

This should not be fixed with a Node 24-specific or Windows-only condition. The stacks API is the source of truth for runtime-specific site configuration on both Windows and Linux. Upcoming runtimes, including .NET 11 on Windows, will also require `use32BitWorkerProcess: false`, while Linux stacks may use the dictionary for other platform-appropriate settings. Every consumer of the stacks API should honor these properties generically so that adding or changing a stack does not require another Azure CLI release or runtime-specific branch.

## Related command

```text
az webapp create
```

Related inspection and workaround commands:

```text
az webapp list-runtimes
az webapp config show
az webapp config set --use-32bit-worker-process false
```

## Errors

The create command succeeds, but the resulting app is configured incorrectly:

```json
{
"nodeVersion": "",
"use32BitWorkerProcess": true,
"windowsFxVersion": null
}
```

After deploying a no-dependency Node probe:

```text
GET https://.azurewebsites.net/
HTTP 500

```

The identical probe on an otherwise identical app where only `use32BitWorkerProcess` is set to `false` returns:

```json
{
"nodeVersion": "v24.18.0",
"architecture": "x64",
"platform": "win32"
}
```

## Issue script & Debug output

The following reproduces the configuration defect on a currently selected subscription. App names must be globally unique.

```powershell
$location = "eastus2"
$resourceGroup = "node24-cli-repro"
$planName = "node24-cli-repro-plan"
$appName = "node24-cli-repro-"

az group create `
--name $resourceGroup `
--location $location

az appservice plan create `
--resource-group $resourceGroup `
--name $planName `
--location $location `
--sku P0v3 `
--is-linux false

az webapp list-runtimes `
--os-type windows `
--query "[?config=='NODE|24LTS']"

az webapp create `
--resource-group $resourceGroup `
--plan $planName `
--name $appName `
--runtime "NODE:24LTS" `
--debug

az webapp config show `
--resource-group $resourceGroup `
--name $appName `
--query "{nodeVersion:nodeVersion, windowsFxVersion:windowsFxVersion, use32BitWorkerProcess:use32BitWorkerProcess}"
```

Runtime discovery correctly returns Node 24:

```json
[
{
"config": "NODE|24LTS",
"os": "Windows",
"runtime": "Node",
"version": "24.0 LTS"
}
]
```

Relevant sanitized `--debug` output:

```text
Will set appsetting {'name': 'WEBSITE_NODE_DEFAULT_VERSION', 'value': '~24'}

PUT .../providers/Microsoft.Web/sites/?api-version=2025-05-01
Request body:
{
"properties": {
"siteConfig": {
"appSettings": [
{
"name": "WEBSITE_NODE_DEFAULT_VERSION",
"value": "~24"
}
],
"alwaysOn": true
},
"serverFarmId": ""
}
}

PUT .../providers/Microsoft.Web/sites//config/metadata?api-version=2025-05-01
Request body:
{
"properties": {
"CURRENT_STACK": "node"
}
}
```

Neither request applies `use32BitWorkerProcess: false`. The resulting value is `true`:

```json
{
"nodeVersion": "",
"use32BitWorkerProcess": true,
"windowsFxVersion": null
}
```

The workaround is:

```powershell
az webapp config set `
--resource-group $resourceGroup `
--name $appName `
--use-32bit-worker-process false
```

## Expected behavior

When `--runtime` selects a Windows or Linux stack whose stacks API entry contains `siteConfigPropertiesDictionary`, `az webapp create` should merge those properties into the `siteConfig` sent to ARM.

For Windows Node 24, the initial create payload should therefore include:

```json
{
"properties": {
"siteConfig": {
"use32BitWorkerProcess": false
}
}
}
```

The implementation should be generalized:

1. Resolve the selected runtime's OS-specific stacks API entry.
2. Apply the valid `siteConfigPropertiesDictionary` entries to the create payload using the SiteConfig schema.
3. Do not hard-code an operating system, runtime name, or version such as Windows, `NODE|24LTS`, or .NET 11.
4. Preserve current defaults when the dictionary or a property is absent.
5. Give an explicit caller-supplied value precedence if `az webapp create` supports an override for the same property.

Regression coverage should verify that:

- Windows Node 24 is created with `use32BitWorkerProcess == false` and can run an x64 probe.
- Another stack carrying the same metadata receives the same setting without a runtime-specific code path. This should cover the upcoming .NET 11 requirement when that stack is available.
- A Linux stack or test fixture carrying site configuration metadata receives its declared properties through the same generalized path.
- A stack without this metadata retains its existing behavior.
- Additional valid SiteConfig properties supplied by stack metadata use the same generalized path.

## Environment Summary

```text
azure-cli 2.88.0
azure-cli-core 2.88.0
azure-cli-telemetry 1.1.0

Python (Windows) 3.14.5
OS Windows 11
```

The issue was reproduced on a Windows P0v3 App Service plan in East US 2. The plan reported `kind: app` and `reserved: false`.

## Additional context

The CLI correctly maps `NODE|24LTS` to `WEBSITE_NODE_DEFAULT_VERSION=~24` and writes `CURRENT_STACK=node`; the missing behavior is propagation of the selected stack's site configuration metadata.

The observed side-by-side test used the same plan and identical deployment package:

| Creation/configuration | `use32BitWorkerProcess` | Result |
|---|---:|---|
| `az webapp create --runtime "NODE:24LTS"` with no post-create change | `true` | HTTP 500 |
| Same create command, followed only by `az webapp config set --use-32bit-worker-process false` | `false` | HTTP 200, Node `v24.18.0`, `x64`, `win32` |

The generalized, OS-independent stacks metadata behavior is the requested fix. A Node 24-only or Windows-only workaround in `az webapp create` would leave the same defect for .NET 11, Linux stacks, and other future runtime requirements.