Deployment submitted twice under the same name, second submission fails the step with DeploymentActive while the first succeeds

### What happened

A single `type: deployment`, `operation: create` step submitted the same deployment name to ARM twice, about 30 seconds apart. The first submission was accepted and ran to completion successfully. The second one was rejected with `DeploymentActive`, and the action failed the step.

The net effect is a false negative: the infrastructure deployed exactly as intended, but the workflow reported failure, which cascaded into every downstream job being skipped.

### Timeline from one run

All times UTC, single job, no retries by us and no concurrent workflow targeting the same resource group.

| Time | Event |
| --- | --- |
| 19:58:51.706 | Action logs `Starting deployment create at resourceGroup '' scope with name ''` |
| 19:59:07 | ARM registers a deployment under that name, correlationId `22e39e73-1fae-41d1-b4cf-3f786036a3cd` |
| 19:59:21.035 | Action reports `Request failed. CorrelationId: f9fd7c69-f160-4418-ac18-50d2c9224f06` with `DeploymentActive`, then `Create failed` |
| 20:00:08.655 | The deployment registered at 19:59:07 completes, `provisioningState: Succeeded`, `duration: PT1M1.34S` |

Two different correlation IDs for what was configured as one deployment is the tell: the client issued the request twice.

Error body, subscription id redacted:

```
{
"code": "DeploymentActive",
"message": "The deployment with resource id '/subscriptions/<sub>/resourceGroups//providers/Microsoft.Resources/deployments/' cannot be saved, because this would overwrite an existing deployment which is still active. If this is an intentional re-deployment, please wait for the original deployment to complete, or cancel it before re-attempting the operation. The previous deployment was started at '9/8/2026 7:59:07 PM' with correlationId '22e39e73-1fae-41d1-b4cf-3f786036a3cd', and will expire at '9/15/2026 7:59:07 PM' if it does not complete before then."
}
```</sub>

### Expected behaviour

Either the submission is not retried, or a retry that hits `DeploymentActive` for the deployment name the action itself just submitted is recognised as its own in-flight request and the action waits on it instead of failing. A deployment that reaches `Succeeded` should not surface as a failed step.

### Why it matters

`DeploymentActive` arrives roughly 30 seconds in, while the real deployment still has most of its runtime left, so the job fails early and the caller has no signal that the work is still progressing and will succeed. In our case the failed leg of a deploy matrix skipped five downstream application-code deployment jobs, leaving the environment on new infrastructure with old application code until the run was manually re-run. The re-run then succeeded with no changes.

It is also awkward to guard against from the outside: a workflow can only work around it by letting the step fail soft and then polling `provisioningState` for the deployment name to decide whether the failure was real.

### Environment

- Action: `azure/bicep-deploy` v2.3.0 (`66910e9c5c7733c33a1cd605030d02234b3bc4ed`)
- Inputs: `type: deployment`, `operation: create`, `scope: resourceGroup`, parameters file `.bicepparam`, `bicep-version: 0.46.1`
- Runner: self-hosted Linux
- Deployment name is deterministic and unique per run (it embeds the run id), so the collision is with the action's own earlier submission, not with a different workflow.

### Notes

I have not been able to determine from the logs whether the first HTTP request failed client side (timeout or 5xx) and was retried, or whether the request is issued twice by design. The action's own log line for starting the deployment appears once, which suggests the duplication happens below that layer. Happy to supply more log detail if useful.

Begin at the deployment create operation in azure/bicep-deploy v2.3.0 and reproduce the duplicate ARM submission using the reported deterministic name and timing. Trace the request or retry path beneath the single start log, then verify that an in-flight DeploymentActive from the action's own request waits for the deployment and that a final Succeeded state leaves the workflow successful.

Written by the indexing model from the issue text.