Bug: Storage Blob Data Owner role assignment name collides across projects sharing a BYO storage account (template 16)

[PreiyaaKedia]

Repro

Template: infrastructure/infrastructure-setup-bicep/16-private-network-standard-agent-apim-setup

Deploy two Foundry projects (or redeploy the same template after recreating the project) against the same BYO storage account. The second deployment either fails or silently corrupts the first project's role assignment.

Root cause

In modules-network-secured/blob-storage-container-role-assignments.bicep the Storage Blob Data Owner role assignment name is computed as:

name: guid(storageBlobDataOwner.id, storage.id)

The GUID only depends on the role definition and the storage account, so the role-assignment name is effectively a singleton per storage account. When a second project is deployed against the same storage account:

The deterministic name collides with the existing assignment.
ARM either returns 409 Conflict, or updates the existing assignment with the new principal/condition — silently breaking the first project's access (its ABAC condition is keyed to its own workspaceId, so once overwritten it can no longer access its containers).
The corresponding ARM line in azuredeploy.json has the same bug.

## Suggested fix
Include aiProjectPrincipalId (and optionally workspaceId) in the GUID inputs:

```bicep
name: guid(aiProjectPrincipalId, workspaceId, storageBlobDataOwner.id, storage.id)

This changes makes
aiProjectPrincipalId makes each project's assignment unique on the same storage account.
workspaceId ties the assignment name to the workspace-scoped ABAC condition embedded in conditionStr, so a workspaceId change yields a fresh assignment instead of reusing one with a stale condition.

The same one-line change must be applied to azuredeploy.json

```bicep
"name": "[guid(parameters('aiProjectPrincipalId'), parameters('workspaceId'), resourceId('Microsoft.Authorization/roleDefinitions', 'b7e6dc6d-f1e8-4753-8033-0f276bb0955b'), resourceId('Microsoft.Storage/storageAccounts', parameters('storageName')))]",

##Notes:
Validated locally: with the GUID fix applied, two projects can share the same BYO storage account without role-assignment collisions.