DeploymentStackDenyAssignmentFailure with "The operation was canceled" — no actionable detail

## Describe the bug

A subscription-scoped deployment stack fails with  DeploymentStackDenyAssignmentFailure  → "The operation was canceled." The failure is not user-initiated and there is no concurrent operation on the stack. The error does not indicate which resource caused the failure or why the operation was canceled, which makes diagnosis effectively impossible.

**Side effect observed:** some resources managed by the failed stack show  denySettings = none  while others in the same stack show  denyWriteAndDelete .

### To Reproduce

We do not have a reliable reproducer. The failure occurred during a normal redeploy of a stack that had previously deployed successfully; the same template targeting other subscriptions in the other tenant continues to succeed.

### Observed sequence:

1. Deploy a subscription-scoped stack
2. Redeploy the same stack later (unchanged or with additional managed resources).
3. Deployment fails with  DeploymentStackDenyAssignmentFailure  (inner:  DeploymentStackOperationFailed  / "The operation was canceled.").
4. Stack is marked  failed . Resources view shows mixed  denyWriteAndDelete  /  none  for managed resources of identical type in the same resource group.
5. Rerunning the same pipeline reproduces the same error — the stack cannot self-recover.

### Expected behavior

• The error message should identify which resource's deny assignment failed and why (which caller/operation canceled it).
• If the deny-assignment phase cannot complete, the deployment should either retry transparently or fail with an actionable cause rather than a bare "operation was canceled".
• Rerunning the same deployment with unchanged input should be able to recover a stack from this state.

Correlation ID: a6c5132a-e250-449d-93ba-b49f3fc53c4f 

### Additional context

• Raw error:
{
"message": "The deny assignment of one or more resources could not be added or removed. Correlation id: 'a6c5132a-e250-449d-93ba-b49f3fc53c4f'.",
"code": "DeploymentStackDenyAssignmentFailure",
"details": [
{ "message": "The operation was canceled.", "code": "DeploymentStackOperationFailed" }
]
}
• No user cancellation, no concurrent stack operation, no manual deny-assignment edits.
• Same template + same  denySettings  succeeds against other subscriptions in the same tenant, so the failure is not caused by the template or the  denySettings  configuration alone.
• The stack cannot self-recover from this state via redeploy.
• Primary ask: surface which resource / which caller / which operation caused the cancellation. Without that, we cannot diagnose or work around this from the client side.