Provide a linux-musl-arm64 Bicep build (Alpine/musl arm64) — az bicep on the official azure-cli Alpine image crashes on arm64 with InsufficientExecutionStackException

### Tracking issue — split out from Azure/azure-cli#28756

Filing here per how the ARM Deployments team tracks Bicep binary/runtime work. The CLI-wrapper half of **Azure/azure-cli#28756** (arch auto-detection) has improved; this issue tracks the **Bicep packaging/runtime** half, which lives in this repo. Original report and thorough write-up by **@KrisSimon**.

### Summary

There is **no `linux-musl-arm64` Bicep build**. The official `mcr.microsoft.com/azure-cli` image is Alpine (musl) — so on **arm64 (aarch64)** there is no matching self-contained Bicep binary. The glibc `linux-arm64` build is what ends up running under musl, and `bicep` then crashes with `System.InsufficientExecutionStackException` — even on an empty file.

### Evidence

The Bicep CLI target platforms exposed by `az bicep install --target-platform` today (Azure CLI 2.85.0) are:

```text
linux-arm64, linux-musl-x64, linux-x64, osx-arm64, osx-x64, win-arm64, win-x64
```

Note: there is a `linux-musl-x64` but **no `linux-musl-arm64`**.

### Repro (from #28756, on linux aarch64 / Alpine)

```
$ touch main.bicep
$ az bicep lint -f main.bicep
ERROR: Unhandled exception. System.InsufficientExecutionStackException: Insufficient stack to continue executing the program safely. ...
at System.Runtime.CompilerServices.RuntimeHelpers.EnsureSufficientExecutionStack()
at Bicep.Core.Syntax.SyntaxVisitor.Visit(SyntaxBase node)
at Bicep.Core.Parsing.Parser.Program()
...
```

That it fires on an essentially empty file (rather than a deeply-nested construct) points at the musl/arm64 runtime stack size, not a specific language construct.

### Requested

1. **Ship a `linux-musl-arm64` self-contained Bicep build** so Alpine/musl arm64 (incl. the official `azure-cli` image) has a matching binary.
2. Investigate the **arm64 default thread stack size** in the parser path (`SyntaxVisitor.Visit` / `Parser.Program`) so it doesn't exhaust the stack on small/empty inputs under musl.

### Workaround (interim)

Use a **glibc arm64 base** (e.g. an Ubuntu 22.04 image with the CLI installed via `aka.ms/InstallAzureCLIDeb`) instead of the Alpine `azure-cli` image — confirmed working by @KrisSimon in #28756.

### Related (closed) — different root cause (construct-triggered deep recursion on x64, not the musl/arm64 packaging gap)

- Azure/bicep#8187, #7455, #6951, #9978, #15265 — all `InsufficientExecutionStackException`, but triggered by specific nested syntax rather than the arm64/musl runtime.

Start by reproducing the failure with `az bicep lint -f main.bicep` on linux aarch64/Alpine and inspect the `SyntaxVisitor.Visit` and `Parser.Program` paths named in the stack trace. Then trace the target platforms exposed by `az bicep install --target-platform` and the Bicep packaging flow. Done means a matching linux-musl-arm64 build is available and an empty input no longer crashes on Alpine arm64.

Written by the indexing model from the issue text.