Support trusted provider hostnames for Pipelines as Code

Problem

Pipelines as Code PR tektoncd/pipelines-as-code#2871 introduces an administrator-owned trusted-provider-hostnames setting and allows each controller to record authenticated, publicly routable self-hosted providers in the pipelinesascode.tekton.dev/auto-trusted-provider-hostnames ConfigMap annotation.

This operator work should begin after that PAC PR is merged and the change is available in a PAC release.

The operator rebuilds PAC ConfigMap data through PAC's vendored Settings type and creates additional PAC controllers from a filtered copy of the primary manifest. Updating only the PAC images/manifests would leave two integration gaps:

• An operator version using an older PAC Settings type cannot round-trip trusted-provider-hostnames through the OpenShiftPipelinesAsCode or TektonConfig settings.
• Additional controllers use their own ConfigMaps but do not currently receive scoped update/patch permission for those ConfigMaps, so they cannot record learned hostnames.

Proposed work

• After tektoncd/pipelines-as-code#2871 merges, bump the PAC dependency and bundled release manifests to a release containing it.
• Ensure trusted-provider-hostnames is accepted and preserved in the primary and additional controller settings maps.
• Give every enabled additional controller scoped update and patch access to its own ConfigMap. Prefer a Role and RoleBinding owned with that additional controller's resources.
• Verify operator reconciliation preserves the controller-owned pipelinesascode.tekton.dev/auto-trusted-provider-hostnames annotation.
• Document configuration through TektonConfig and OpenShiftPipelinesAsCode, including the upgrade requirement for self-hosted providers using per-repository or incoming webhooks.

Example primary-controller configuration:

spec:
  platforms:
    openshift:
      pipelinesAsCode:
        settings:
          trusted-provider-hostnames: "ghe.example.com,gitlab.example.com"

Acceptance criteria

• The PAC dependency and manifests contain tektoncd/pipelines-as-code#2871.
• Primary and additional controller settings retain trusted-provider-hostnames after defaulting and reconciliation.
• Each additional controller can patch only its configured ConfigMap for learned-host annotation updates.
• Operator reconciliation does not remove the learned-host annotation.
• Tests cover settings conversion, additional-controller RBAC, and annotation preservation.
• Operator documentation explains configuration and upgrade behavior.

Start after tektoncd/pipelines-as-code#2871 is released, then inspect the vendored Settings conversion and reconciliation paths for primary and additional controllers. Review the bundled manifests and additional-controller RBAC resources, and add coverage for settings retention, scoped ConfigMap permissions, and annotation preservation. Done means the acceptance criteria pass and TektonConfig, OpenShiftPipelinesAsCode, and upgrade behavior are documented.