Static Web Apps: all deployments fail "An unknown exception has occurred" at upload phase.

SWA deployment fails immediately after DeploymentId: with the swallowed An unknown exception has occurred. Adding details that may help narrow it:

1. Not East US 2 specific. I provisioned a brand-new clean Standard SWA in West US 2 (purple-dune-0c3b1fc1e.7.azurestaticapps.net) — same failure mode, environment stuck in WaitingForDeployment. So whatever this is, it isn't isolated to c2gp-slice-0-eus2-0-ase.

2. Older binary doesn't help. Tested both 689a6c1fe8fc32f40348cc41223a7e9d83dd43d2 (current manifest) and 08e29138cd3dcda4ffda6d587aa580028110c1c7 (the previous binary still cached on the CDN). Both fail identically with the opaque exception. The CDN has purged everything older than 08e29138..., so the #881-style "patch deploy-client.js to skip version check" workaround is not available.

3. Cross-platform, cross-client. Reproduced from:
- Linux/WSL (Ubuntu 24.04), SWA CLI 2.0.7 and 2.0.9
- Windows 10, SWA CLI 2.0.9
- Direct StaticSitesClient upload and run --deploymentaction upload invocation, bypassing the Node CLI entirely

Same failure in every combination. Empty stderr — the inner exception is fully swallowed by the binary's top-level handler.

4. Token + auth are fine. Generic Azure ops (az staticwebapp commands, blob storage reads/writes, the live site at HTTP 200) all work. Token regeneration via az staticwebapp secrets reset-api-key made no difference.

Sample failed Deployment IDs (today):
- f72e13b9-7b8e-48c3-a614-1176ded81411 (Linux, older 08e29138 binary, full payload)
- c7bd5ed0-f19f-43bb-8281-03a0a846c3f8 (Linux, older binary, minimal 1-file payload)
- bca82c7a-0bfa-4725-86f2-372a6c83acf1 (Linux, current 689a6c1f binary)
- East US 2 SWA: swa-conquest-demo (subscription ID available privately)
- West US 2 SWA (now deleted): swa-conquest-demo-wus2

This has been open ~3 weeks without an Microsoft response. Any chance of an ack from the team that this is being investigated? The "WaitingForDeployment" state plus swallowed inner exception makes it impossible to self-diagnose further from the client side.

Start with the StaticSitesClient upload invocation and the SWA CLI paths described in the report, reproducing the failure with the listed current and cached binaries. Compare behavior across the supplied deployment IDs and platforms, then determine why the inner exception is swallowed. Done means the upload completes or reports an actionable failure instead of leaving the deployment in WaitingForDeployment.

Written by the indexing model from the issue text.