Fix role assignment for existing Foundry resources

[Changjian Wang (changjian-wang)]

Summary

Fixes #28.

• Preserve explicit --assign-roles true and false values when standalone cu infra generate reuses an existing Foundry endpoint. Omitted values remain false, and existing-resource generation does not prompt for role assignment.
• Add an opt-in Cognitive Services User role assignment scoped to accountExisting in the shared Bicep template, using a deterministic assignment name. The new-resource path remains unchanged.
• Add regression coverage for interactive/noninteractive resolution, standalone/Azure CLI generation parity, account-scoped template conditions, and postprovision launcher failure exit-code propagation.
• Update provisioning and generated-project documentation with the resolved-choice contract, required permissions, and RBAC propagation caveat.

Validation

• Full local Windows CI: bash cu-cli/scripts/ci.sh completed with exit code 0, including wheel builds, Ruff, mypy, unit tests, installed-wheel parity, and offline integration playback. Platform-specific/live-only skips remain in place.
• Source and generated Bicep templates compiled successfully with no diagnostics; the compiled existing-account role assignment condition and scope were inspected.
• Manual standalone generation against a real existing Foundry resource: omitted / explicit false / explicit true all exited 0 and produced AZD_ASSIGN_ROLES=false / false / true, respectively. The generated template contains roleCogUserOnExisting scoped to accountExisting.
• Editor diagnostics and git diff --check passed.

Cloud Validation Limitation

azd provision --preview was attempted but returned 403 AuthorizationFailed for Microsoft.Resources/deployments/whatIf/action at subscription scope. The test identity therefore could not proceed to deployment.

No real role-assignment deployment or cloud postprovision execution was performed. This preview permission failure is not counted as the role-assignment-deployment-failure regression scenario. Live success and role-assignment failure behavior still require verification with appropriately permissioned test identities.

Role assignment remains part of the required initial Bicep deployment; the existing postprovision contract and launchers are unchanged.