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

## 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 #25 at `b5255cbd94a9353c5d8812e8bf68ff6e2a1abf88`

## Reproduction Steps

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

```sh
cu infra generate \
--foundry-endpoint https://.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:

```python
resolved_assign_roles = False if use_existing_foundry else (...)
```

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

```bicep
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.

Start at the standalone `cu infra generate` role-resolution path and compare it with the `az cu` behavior described in PR #25. Then inspect the canonical Bicep existing-resource path and postprovision login configuration. Add coverage for omitted, false, and true role options, including deployment failure, and confirm generated `AZD_ASSIGN_ROLES`, role assignment, and login readiness match the requested choice.

Written by the indexing model from the issue text.