Document Entra claims-mapping policy signing-key requirements

[drernie]

Context

Austin reported in PR #4903 that an Entra deployment using a claims-mapping policy began failing with AADSTS50146 after group-based role mapping was configured. The reported configuration had neither an application-specific signing key nor acceptMappedClaims enabled.

The basic Token configuration → Add groups claim path documented for Quilt is distinct from assigning a claims-mapping policy. We should document the advanced policy path without implying that every built-in groups claim needs a custom signing key.

Original report: #4903 (comment)

Microsoft references:

• https://learn.microsoft.com/en-us/entra/identity-platform/reference-claims-customization
• https://learn.microsoft.com/en-us/entra/identity-platform/jwt-claims-customization
• https://learn.microsoft.com/en-us/graph/api/resources/claimsmappingpolicy?view=graph-rest-1.0

Work

• Reproduce or otherwise verify when an assigned claims-mapping policy triggers AADSTS50146 for Quilt OIDC applications.
• Clearly distinguish built-in optional/group claims from claims-mapping policies.
• Document the supported remedy for single-tenant applications and the security limitations of acceptMappedClaims.
• Document application-specific signing-key setup for multi-tenant applications, including the currently required manifest/service-principal fields.
• Explain that removing a groups claim from Token configuration does not detach an assigned claims-mapping policy.
• Add troubleshooting steps for detecting and removing a stale policy assignment.
• Cross-link the guidance from the Entra and SSO permissions-mapping documentation.

Acceptance criteria

• Guidance is verified against current Microsoft documentation and a working Entra configuration.
• AADSTS50146 recovery is covered for both single-tenant and multi-tenant applications.
• Existing group-overage and App roles guidance remains accurate and non-duplicative.