Add support for setting custom labels on Concierge impersonation proxy Services through the CredentialIssuer API.

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

Yes, credentialIssuer.impersonationProxy.service.annotations lets users add custom annotations to the Concierge impersonation proxy Service, but there is no equivalent field for labels.

This is limiting for environments where platform tooling relies on Service labels.
Today, users can manually label the generated Service, but that is fragile because the Service is managed by the Concierge controller.

Describe the solution you'd like

Add support for configuring custom labels on the impersonation proxy Service through the CredentialIssuer API, for example:

spec:
  impersonationProxy:
    service:
      labels:
        example.com/team: platform
        example.com/component: auth

The Concierge controller should apply these labels to the generated impersonation proxy Service for both supported managed Service types:

• LoadBalancer
• ClusterIP

The behavior should match the existing annotation behavior:

• Preserve Pinniped’s existing controller labels.
• Merge user-provided labels onto the generated Service.
• Let the CredentialIssuer value win for managed label keys.
• Preserve unrelated labels added by other actors.
• Remove previously managed labels when they are removed from the CredentialIssuer spec.

Describe alternatives you've considered

Users can manually add labels to the generated Service after it is created, but this is not ideal because the Service is controller-managed and may be reconciled or recreated.

Another alternative is to rely only on annotations, but many Kubernetes tools and organizational policies specifically use labels for selection, grouping, ownership, reporting or automation.

Are you considering submitting a PR for this feature?

Yes.

• How will this project improvement be tested?
  Unit tests for the impersonator config controller should verify that custom labels from CredentialIssuer.spec.impersonationProxy.service.labels are applied to both LoadBalancer and ClusterIP Services.
  Tests should also verify label reconciliation behavior, including merging, conflict handling, preserving unrelated labels, and removing labels that were previously managed by the CredentialIssuer spec.

• How does this change the current architecture?
  This should be a small extension of the existing CredentialIssuer service configuration and Service reconciliation logic.
  The controller already supports applying custom annotations to the generated Service and already has bookkeeping logic for managed label keys. This feature would reuse that pattern for user-provided Service labels.

• How will this change be backwards compatible?
  The new labels field would be optional. Existing CredentialIssuer resources that do not set it would continue to behave as they do today.
  Existing Pinniped controller labels would continue to be applied. Existing Service annotations behavior would not change.

• How will this feature be documented?
  The CredentialIssuer API documentation and generated CRD/API reference should document the new optional field:
  spec.impersonationProxy.service.labels
  Documentation should mention that these labels are applied to the managed impersonation proxy Service when the Service type is LoadBalancer or ClusterIP.

Additional context

This would make Service label customization consistent with the existing Service annotation customization.

Start with the impersonator config controller and its existing custom-annotation reconciliation, then inspect the CredentialIssuer API definition and generated CRD/API reference. Run the impersonator config controller unit tests; done means the optional labels field is documented and labels reconcile correctly for LoadBalancer and ClusterIP Services, including merging, conflicts, unrelated labels, and removal.