deploymentStacks: reject partially-unresolved ${VAR} in deny-list entries

## Context

Follow-up from PR #9238 (`${VAR}` substitution in `infra.deploymentStacks`).

`resolveDeploymentStacksValues` (`cli/azd/pkg/infra/provisioning/bicep/deployment_stacks.go`) currently rejects an entry only when the **entire** expanded value trims to empty. Composite entries with an unset variable slip through:

```
Microsoft.Authorization/${UNSET_SCOPE}/write -> Microsoft.Authorization//write (sent to ARM)
```

`excludedPrincipals` is usually a bare `${VAR}` (so a full-blank result is caught), but `excludedActions` entries are commonly composite and more likely to hit this.

## Constraint

The fix cannot simply key off `len(lookedUpEmpty) > 0`: the `Envsubst` callback records the variable name for `${VAR:-fallback}` **before** the default is applied, so a naive check would reject valid defaulted values and break `TestResolveDeploymentStacksMap_DefaultExpression`.

## Proposed fix

Detect a variable reference that was genuinely unset **and** not satisfied by a default (e.g. compare the pre/post-expansion for that specific reference, or evaluate each reference individually), and error out with the offending variable name. Keep `${VAR:-default}` working. Add a regression test for a composite `excludedActions` entry with an unset variable.

## Scope / priority

Alpha feature (`AZD_ALPHA_ENABLE_DEPLOYMENT_STACKS`); limited blast radius. Non-blocking; raised by @jongio and @richardpark-msft on PR #9238.

Start in cli/azd/pkg/infra/provisioning/bicep/deployment_stacks.go at resolveDeploymentStacksValues, then inspect TestResolveDeploymentStacksMap_DefaultExpression to understand default handling. Add a regression test for a composite excludedActions entry with an unset variable; done means it errors with the variable name while ${VAR:-default} remains valid.

Written by the indexing model from the issue text.