SWA obscures underlying errors reported by StaticSitesClient

**Describe the bug**

When doing an `swa deploy`, errors executing `StaticSitesClient` are hidden from the output, even with `--verbose=silly` enabled.

This is related to something mentioned in passing in #615, but unlike that issue, I want this issue to focus on the errors being hidden as the bug being discussed, rather than whatever might be triggering the underlying error.

In my case, I had one of the same issues as #615 (I hadn't installed libicu, so StaticSitesClient was failing). However, I was stuck on this for quite a while because all I saw was:

```
$ npx @azure/static-web-apps-cli deploy --verbose=silly
[...]
Deploying using /home/user/.swa/deploy/53b7d0e07fe5c34bf68929fab92f87ce910288dc/StaticSitesClient@53b7d0e07fe5c34bf68929fab92f87ce910288dc
[...]
Deploying project to Azure Static Web Apps...
⠧ Preparing deployment. Please wait...
```

Not only was the output hidden, but it never timed out, even though the `StaticSitesClient` binary immediately crashed upon launch. The only way for me to see the error was manually invoking the (largely undocumented) client like so:

```
$ ~/.swa/deploy/53b7d0e07fe5c34bf68929fab92f87ce910288dc/StaticSitesClient
Process terminated. Couldn't find a valid ICU package installed on the system. Please install libicu (or icu-libs) using your package manager and try again. Alternatively you can set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support. Please see https://aka.ms/dotnet-missing-libicu for more information.
at System.Environment.FailFast(System.String)
at System.Globalization.GlobalizationMode+Settings..cctor()
at System.Globalization.CultureData.CreateCultureWithInvariantData()
at System.Globalization.CultureData.get_Invariant()
at System.Globalization.TextInfo..cctor()
at System.String.ToLowerInvariant()
at System.Text.EncodingHelper.GetEncodingFromCharset()
at System.ConsolePal.GetConsoleEncoding()
at System.Console.get_OutputEncoding()
at System.Console.CreateOutputWriter(System.IO.Stream)
at System.Console.g__EnsureInitialized|26_0()
at System.Console.WriteLine(System.String)
at StaticSitesClient.Program.Main(System.String[])
Aborted (core dumped)
```

I think at a minimum the above error text should have been output by SWA to give a clue as to the problem.
And ideally, the process failing in this way should result in SWA terminating with an error. There is no sense waiting for something that will never finish.

**To Reproduce**

While the below steps show how to _reproduce_ the error by _deliberately_ omitting the libicu dependency, consider that this problem can occur with any possible error that would cause StaticSitesClient to terminate (bug, API error, other runtime dependency issue, out of memory). The real problem is the confusion and lack of useful output, not what might trigger the error.

1. Cause StaticSitesClient to error on launch by removing libicu. For example, on the latest `fedora:41` container:
```
$ dnf remove libicu # WARNING: do not run this on a system you care about. on my minimal system, it removes cleanly, but if it wants to remove your entire GNOME desktop consider a different machine.
```
2. `~/.swa/deploy/*/StaticSitesClient` should return an error at this point
2. Run `swa deploy`
2. Observe that the error isn't propagated to `swa`, and it hangs on `Preparing deployment. Please wait...`

**Expected behavior**

I expect the error from StaticSitesClient to be reported to the user.

I don't think SWA should reinterpret and obscure the error, as it might not be possible to catch every single error. For example, in #867 the root cause was the wrong architecture binary being run, and the error behaviour would be highly platform or issue specific.

**Desktop (please complete the following information):**

I reproduced the issue on:

- Workstation: Fedora Silverblue 41 updated to latest at time of writing
- with a Podman container running the latest `fedora:41` container at time of writing, with Node.js v22.11.0 runtime

Parti dal punto di ingresso `swa deploy` e segui come avvia `StaticSitesClient`, in particolare la gestione del suo output, dello stato di uscita e dello stato di attesa. Riproduci il malfunzionamento rimuovendo `libicu` in un container Fedora 41; l’attività è completata quando viene mostrato l’errore del client e `swa deploy` termina invece di rimanere bloccato.

Scritto dal modello di indicizzazione a partire dal testo della issue.