Model authentication policies for Azure Sandbox deployment endpoints

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

The Azure Sandbox integration currently lets developers choose whether a deployed endpoint is anonymous, but it cannot express who should be allowed to access a protected endpoint.

Azure Sandbox supports richer authentication policies for both Microsoft Entra ID and GitHub. Entra policies can identify allowed emails, email suffixes, object IDs, and tenant IDs. GitHub policies can identify allowed emails, email suffixes, usernames, and username suffixes. Aspire currently has no app-model or deployment configuration capable of preserving that intent.

This gap makes it difficult to describe least-privilege access for interactive users, groups, service principals, managed identities, GitHub users, and automated deployment or validation systems.

### Describe the solution you'd like

Aspire should provide a way for developers to encode the intended authentication and authorization policy for Azure Sandbox deployment endpoints, covering both Microsoft Entra ID and GitHub authentication.

This issue is intended to track the capability gap and subsequent design work. It deliberately does not prescribe an API shape or implementation approach.

### Additional context

This is distinct from temporarily allowing the deploying identity to perform deployment-time endpoint readiness checks. The persisted endpoint policy should represent the application's intended access policy rather than an incidental property of who performed the deployment.

Related: #19809 discusses a specific Connector Namespace managed-identity callback scenario, but not general endpoint policy modeling.

Start by reviewing the existing Azure Sandbox deployment endpoint configuration and related issue #19809. Define how persisted policies should represent Microsoft Entra ID and GitHub access constraints without prescribing an API prematurely. Done means a decided design covering the listed identity and allow-list fields for both authentication providers.

Written by the indexing model from the issue text.