A Kudu HTTP 500 is reported as "Failed to use <file> as ZipDeploy content", which reads as a malformed package

### Summary

When Kudu returns `HTTP 500` from `/api/zipdeploy`, the action reports it as:

```
When request Azure resource at PublishContent, zipDeploy :
Failed to use /home/runner/work/_temp/temp_web_package_.zip as ZipDeploy content
```

That phrasing reads as "your package is malformed." In our case the package was fine and the failure was entirely server-side. It sent the first hour of an outage investigation in the wrong direction.

### Full error as emitted

```
##[error]Failed to deploy web package to App Service.
##[error]Execution Exception (state: PublishContent) (step: Invocation)
##[error] When request Azure resource at PublishContent, zipDeploy : Failed to use /home/runner/work/_temp/temp_web_package_9901128806427408.zip as ZipDeploy content
##[error] Failed to deploy web package to App Service.
Internal Server Error (CODE: 500)
##[error] Error: Failed to deploy web package to App Service.
Internal Server Error (CODE: 500)
at Kudu. (/home/runner/work/_actions/Azure/functions-action/v1/lib/appservice-rest/Kudu/azure-app-kudu-service.js:238:41)
```

The innermost, accurate fact — `Internal Server Error (CODE: 500)` from Kudu — is two levels in, beneath a line that names our local zip as the suspect.

### Why it misleads

The outer line names the local artifact, so the natural reading is that the artifact is at fault. Three things had to be checked before that could be ruled out:

- the build's own gate had already verified the package (correct function count derived from the built output)
- `npm` resolved byte-identical dependency counts to the previous successful deploy
- no integrity complaint appears anywhere in the run log

The package was valid. The server was returning 500 because writes to the app's content share had degraded to ~1 MB/s, so a 218 MB upload could not complete inside the SCM gateway's ~90s window. Nothing about that is discoverable from the message.

The stack frame is also informative and not surfaced in the summary: the throw originates in `azure-app-kudu-service.js`, i.e. in the code that *interprets Kudu's response*, not in archiving or local packaging. A genuinely bad local zip would fail earlier.

### Suggested improvement

When the underlying failure is an HTTP status from Kudu, lead with that rather than with the local filename. Something like:

```
zipDeploy failed: Kudu returned HTTP 500 (Internal Server Error) for .
The package was uploaded from ; this status originates on the server,
not from the package contents.
```

Even just reordering so the HTTP status is the headline and the local path is context would help. A 5xx is a server condition, and the current wording attributes it to the user's artifact.

### Related

Filed the underlying destructive behaviour separately as Azure/azure-functions-host#11989 — a failed `zipdeploy` under `WEBSITE_RUN_FROM_PACKAGE=1` removed the previously-active package, which is what turned this failed deploy into a 90-minute outage.

Start in lib/appservice-rest/Kudu/azure-app-kudu-service.js around line 238, where the Kudu response is interpreted for zipDeploy failures. Trace the HTTP 500 path and verify that the emitted message leads with Kudu's status and keeps the local package path as context; done means server-side failures no longer read as malformed packages.

Written by the indexing model from the issue text.