Remote state has no per-environment isolation boundary, so one environment's identity can read and write every other environment's state

### Problem

All environments in a remote state store share a single blob container, separated only by a blob name prefix:

```go
// cli/azd/pkg/environment/storage_blob_data_store.go
return fmt.Sprintf("%s/%s", env.name, DotEnvFileName)
return fmt.Sprintf("%s/%s", env.name, ConfigFileName)
```

Azure Storage data-plane RBAC roles are assignable at subscription, resource group, storage account, and container scope. They are not assignable at blob-prefix scope without hand-authored ABAC conditions. There is therefore no supported way to grant a principal access to one environment's state and not the others.

### Impact

Any principal that can use remote state for one environment can read and write the state of every environment in that store. Environment state includes resolved infrastructure outputs, connection endpoints, resource identifiers, and any values callers have set, which in practice includes sensitive material.

This makes remote state unusable for the common case where lower and higher environments must be operated by different identities with least privilege. Adopting remote state requires accepting that a lower-environment identity holds read and write access to the higher environment's state. That is a direct conflict with the environment-isolation posture that separate environments exist to provide, and it is not called out in the documentation.

The workaround, a separate storage account per environment, discards the single-store model the feature is built around and multiplies the infrastructure and configuration required.

### Proposed requirement

Remote state must support an isolation boundary that Azure RBAC can actually express.

1. Allow the container to be resolved per environment, so each environment can live in its own container with independent role assignments. A template such as `containerName: azd-state-${AZURE_ENV_NAME}` would be sufficient.
2. Alternatively or additionally, support a distinct backend configuration per environment.
3. Document the isolation model explicitly either way, including the minimum role assignment and its blast radius, so operators can make an informed decision before adopting the feature.

### Acceptance criteria

- [ ] Container (or full backend config) can differ per environment
- [ ] Documentation states the exact scope of access a remote state role assignment confers
- [ ] Documentation shows a least-privilege configuration where one environment's identity cannot read another's state
- [ ] Existing single-container stores keep working unchanged

Start with cli/azd/pkg/environment/storage_blob_data_store.go and trace how the remote-state container and blob names are resolved per environment. Review the proposed container or backend configuration options and document the role-assignment scope and least-privilege setup. Done means environments can use independent boundaries, existing single-container stores still work, and the acceptance criteria are documented.

Written by the indexing model from the issue text.