[AVM Module Issue] ai-foundry preview/what-if fails when internal RBAC uses same-deployment principal IDs

### Module path

avm/ptn/ai-ml/ai-foundry

### Module version

`0.6.0`

### Summary

Preview flows fail before a what-if result is produced when the AI Foundry pattern creates internal associated-resource RBAC assignments from principal IDs that are only materialized later in the same deployment.

In our repo this shows up through both:

- `azd provision --preview`
- `az deployment sub what-if --validation-level Template`

The raw preview path fails with:

```text
InvalidTemplate: The provided value for the template parameter 'roleAssignments[0]' is not valid. A non-null value for the property 'principalId' must be provided, but the property was null or missing.
```

### Repro shape

The repro uses the AI Foundry pattern with associated resources enabled, including AI Search and Storage, so the module synthesizes RBAC for those resources and for the created project.

### Compiled template evidence

From the compiled ARM output generated from the module usage:

- the storage associated-resource deployment builds `roleAssignments` by concatenating user-provided assignments with new entries whose `principalId` values come from `reference('foundryAccount').outputs.systemAssignedMIPrincipalId.value` and `reference('aiSearch').outputs.systemAssignedMIPrincipalId.value`
- the project-related RBAC deployments pass `reference('project', '2025-07-01-preview', 'full').identity.principalId` into nested role-assignment deployments

Those same-deployment identity references are valid for real deployment ordering, but preview validation appears to evaluate them too early.

### Why this seems module-related

We already moved some repo-local RBAC assignments outside the AI Foundry module to reduce preview failures, but the remaining failure still comes from the module's internal associated-resource/project RBAC generation.

### Expected behavior

The module should remain previewable in ARM what-if / `azd provision --preview`, even if the actual role assignments are created later in the deployment.

### Actual behavior

Preview fails during template validation and produces no usable diff unless the caller strips the preview-hostile RBAC sections from a temporary compiled template.

### Suggested fix directions

1. Avoid constructing preview-critical `roleAssignments` arrays from same-deployment managed-identity outputs inside the main pattern path.
2. Split those associated-resource RBAC deployments into a phase that can be disabled or deferred for preview-sensitive scenarios.
3. Expose an option to skip/defer internal associated-resource RBAC and project-connection RBAC so callers can keep preview working without forking the module.
4. Where possible, prefer existing-resource lookups for already-deployed resources instead of preview-time references to fresh outputs.

### Environment

- `azd 1.23.15`
- `azure-cli 2.84.0`
- preview attempted at subscription scope

If helpful, I can provide a minimized repro that isolates just the AI Foundry pattern and the failing associated-resource RBAC path.