Partner Admin Link deployment is not idempotent — fails if Partner ID already exists

**Bicep version**
`Bicep CLI version 0.36.177 (09988bb4ae)`

---

**Describe the bug**
When attempting to deploy a `Microsoft.ManagementPartner/partners@2018-02-01` resource via Bicep to create a Partner Admin Link, the deployment fails with the following error:

```
(PartnerIdAlreadyLinked) This user or service principal is already linked with a Partner ID
```

This is wrapped inside a `DeploymentFailed` and `DeploymentStackDeploymentFailed` error, making troubleshooting more difficult without drilling into the nested exceptions.

**Expected behaviour**
If a Partner ID is already linked, the deployment should either:

* Succeed with no changes (idempotent), or
* Expose a mechanism to check existence and skip creation/update gracefully.

---

**To Reproduce**

1. Create a Bicep template that includes the following:

```bicep
targetScope = 'managementGroup'

param partnerAdminLinkId string

resource rPartnerAdminLink 'Microsoft.ManagementPartner/partners@2018-02-01' = {
name: partnerAdminLinkId
scope: tenant()
}
```

2. Deploy this template using a service principal already associated with the given Partner ID.
3. Observe the deployment failure with the error code `PartnerIdAlreadyLinked`.

---

**Additional context**

* Deployment initiated via: Azure Deployment Stacks (or `az stack mg`)
* This issue breaks deployment idempotency and prevents repeatable infrastructure-as-code pipelines.

**Suggested Fix or Workaround**

* Allow conditional creation of the PartnerAdminLink resource in Bicep.
* Alternatively, suppress this error when the Partner ID is already linked (no-op).
* Improve error visibility or diagnostics in the Bicep CLI when deployment fails at the tenant or management group scope.

Start with the Bicep template and deployment steps in the issue, using Azure Deployment Stacks or `az stack mg` and the `Microsoft.ManagementPartner/partners@2018-02-01` resource. Confirm the `PartnerIdAlreadyLinked` behavior and determine whether the actionable change belongs in the type definitions or Azure deployment behavior. Done means repeat deployment has the requested idempotent or graceful-existence behavior, with clearer diagnostics if that is the supported scope.

Written by the indexing model from the issue text.