[P1] Support role assignment for existing Foundry resources in cu infra generate

[yungshinlintw]

Summary

Standalone cu infra generate ignores an explicit role-assignment request when reusing an existing Microsoft Foundry resource.

Environment

• Product: Standalone CU CLI
• Affected command: cu infra generate
• Observed in: PR Add native Azure CLI Content Understanding extension #25 at b5255cbd94a9353c5d8812e8bf68ff6e2a1abf88

Reproduction Steps

1. Run infrastructure generation with an existing resource and explicitly request role assignment:

   cu infra generate \
     --foundry-endpoint https://<account>.services.ai.azure.com/ \
     --assign-roles true

2. Inspect AZD_ASSIGN_ROLES in the generated azd environment.

3. Inspect the existing-resource path in the generated Bicep.

Expected Behavior

An explicit --assign-roles true should be preserved. During azd up, Bicep should assign Cognitive Services User to the invoking principal on the existing Foundry account. After that deployment succeeds, postprovision should configure the CU profile for login authentication.

Omitting the option should remain conservative and default to no role assignment.

Actual Behavior

Standalone unconditionally resolves role assignment to false whenever --foundry-endpoint is supplied, even if the user explicitly requests it:

resolved_assign_roles = False if use_existing_foundry else (...)

The canonical Bicep also creates a role assignment only for a new resource:

if (!useExistingFoundry && assignRolesToPrincipal && !empty(principalId))

As a result, users cannot ask the standalone workflow to establish Entra data-plane access for an existing resource. They must configure RBAC separately or fall back to resource-key authentication.

Impact

P1 / High - Reusing an existing resource is a primary provisioning scenario. Users with management access but without Cognitive Services User cannot request the required data-plane role through the standalone workflow. This is especially important when local/key authentication is disabled or organizational policy requires Entra authentication.

Proposed Resolution

1. Preserve explicit --assign-roles true for existing resources while retaining false as the omitted default.
2. Add an account-scoped role assignment for accountExisting in the canonical Bicep.
3. Configure login authentication only after the role-assignment deployment succeeds.
4. Apply the same resolved-choice contract to standalone cu and az cu.
5. Add tests for:
   • existing endpoint with omitted role option;
   • existing endpoint with explicit false;
   • existing endpoint with explicit true;
   • role-assignment deployment failure not claiming login readiness.

Additional Context

PR #25 currently exposes the opposite half of this behavior in az cu: Azure can preserve assign_roles=true for an existing endpoint, but canonical Bicep still does not create the assignment while postprovision can assume login authentication is available. The shared fix should complete the feature for both frontends rather than normalize both to the standalone limitation.