Improve Multi-IDP Developer Experience for Enterprise Adoption

## Feature Proposal

While CALM Hub's secure profile uses generic Quarkus OIDC and technically supports any OIDC-compliant provider, the current developer experience and documentation are heavily Keycloak-centric:

- The only bundled local dev IDP is Keycloak (via Testcontainers)
- Default configuration in application-secure.properties uses Keycloak-style realm URLs
- No documented configuration examples or guides for other enterprise IDPs
- No tested/validated integration with providers like Microsoft Entra ID, Okta, Auth0, or Google Identity
- Role/group mapping strategies may differ across providers and are not documented

Enterprises evaluating CALM Hub need confidence that their existing IDP integrates smoothly without trial-and-error.

**Related Issue**

Builds on #2867 (Supporting GitHub as a Data Source) — as CALM Hub expands its data source integrations, the authentication layer needs equally flexible IDP support for enterprise adoption.

### Target Project:
...which existing project in the monorepo will this feature be added to?

### Description of Feature:
...what capabilities will the new feature provide, and why is it needed?

### User Stories:
...describe the feature from an end-user perspective, using "As a [role], I want [feature] so that [benefit]" format...

### Current Limitations:
...describe why this functionality isn't possible with the current implementation...

### Proposed Implementation:
...provide details of the intended implementation approach, including:
- Technical design considerations
- API changes (if applicable)
- Data model changes (if applicable)
- Dependencies on other components

### Alternatives Considered:
...what other approaches were considered and why were they rejected?

### Testing Strategy:
...how will this feature be tested? Include unit, integration, and any other testing considerations...

### Documentation Requirements:
...what documentation will need to be created or updated?

### Implementation Checklist:
- [ ] Design reviewed and approved
- [ ] Implementation completed
- [ ] Tests written and passing
- [ ] Documentation updated
- [ ] Relevant workflows updated (if needed)
- [ ] Performance impact assessed

### Additional Context:
...add any other context, diagrams, mockups, or screenshots about the feature request here...

Start with application-secure.properties and the existing Keycloak Testcontainers setup, then review the Quarkus OIDC configuration and current documentation. Done should include a decided approach for validating non-Keycloak providers, documented configuration and role/group mappings, and corresponding tests or integration coverage.

Written by the indexing model from the issue text.