fix(deploy.sh): stop reporting "Deployment FAILED" on successful deployments

[Felipe Binotto (fbinotto)]

Summary

./bin/deploy.sh printed ══════════ Deployment FAILED ══════════ and exited 1 even when ARM reported provisioningState: Succeeded, which aborted the run before apply-extras.sh could apply the data-plane config (skills, subagents, hooks, prompts, scheduled tasks, incident filters).

Root cause

Two independent defects in the post-deployment result handling:

stderr was merged into the JSON output. The deployment ran with --output json > "$TMP" 2>&1. Azure CLI writes Bicep linter output (WARNING: ... no-unused-params, BCP081, BCP318, etc.) to stderr, so those lines were prepended to $TMP. The file was therefore not valid JSON, jq -r '.properties.provisioningState' failed, and the || echo "Failed" fallback set STATE=Failed. Any template emitting a linter warning triggered this — i.e. effectively every deployment.

The ARM fallback was unreachable. The recovery path was guarded by if [[ "$STATE" == "?" && $AZ_RC -ne 0 ]]. Under the script's set -euo pipefail, a failing az command terminates the script before AZ_RC=$? is ever evaluated, so AZ_RC was always 0 at that point. The condition could never be true, and AZ_RC was otherwise unused.

Changes

Capture Azure CLI stderr in a separate temp file (TMP_ERR) so $TMP holds pure JSON; stderr is still echoed to the terminal so linter warnings remain visible.
Append || true to the az deployment sub create call so set -e no longer kills the script before the result handling and error diagnostics can run.
Remove the now-dead AZ_RC variable.
Query ARM for the real provisioningState whenever the JSON parse yields nothing or ?, instead of only on a non-zero exit code; default to Failed only if ARM also returns nothing.
On the failure path, fall back to TMP_ERR for the root-cause message when the response body contains no .message (e.g. CLI/auth failures that never produce a deployment JSON).

Behaviour after the fix

Successful deployment with linter warnings → reported as succeeded, apply-extras.sh runs, connector health check runs.
Genuinely failed deployment → still reported as failed, exits 1, with a root cause from either the ARM error body or CLI stderr.
Existing RoleAssignmentExists soft-failure handling on redeploy is unchanged.