Description of problem:

Under OpenShift Pipelines 1.15.1, the Pipelines-as-Code resolver will modify PipelineRuns created under the v1 and v1beta1 APIs and remove the `podTemplate` rather than mutating it.

The correct usage for each version is

When using the wrong spec/API combo, i.e. v1beta1 and `spec.taskRunTemplate.podTemplate` or v1 and `spec.podTemplate`, the PaC resolver will instead drop the field, rather than mutate accordingly.

There is no present workaround other than correcting the PipelineRun definitions to match the expected specification.

Prerequisites (if any, like setup, operators/versions):

OpenShift 4.15.x

OpenShift Pipelines 1.14, 1.15

Steps to Reproduce

1. Install Pipelines >= 1.14 to an OCP 4.15.x cluster
2. Create PaC repo (or use `tkn pac resolve`)
3. Create and run bad PLR manifests:

---
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: badplr-v1
spec:
  pipelineSpec:
    tasks:
      - name: noop-task
        taskSpec:
          steps:
            - name: noop-task
              image: registry.access.redhat.com/ubi9/ubi-micro
              script: |
                exit 0
  podTemplate:
    securityContext:
      runAsNonRoot: true
      runAsUser: 1001

---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: badplr-v1beta1
spec:
  pipelineSpec:
    tasks:
      - name: noop-task
        taskSpec:
          steps:
            - name: noop-task
              image: registry.access.redhat.com/ubi9/ubi-micro
              script: |
                exit 0
  taskRunTemplate:
    podTemplate:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1001

Actual results:

PaC resolver will strip the affect field away (podTemplate for v1, taskRunTemplate for v1beta1).

Expected results:

PaC either mutates the field to match the v1 spec, or leaves the field intact and allows the webhook to handle denial / mutation.

Reproducibility (Always/Intermittent/Only Once):

Intermittent. Issue was reported as occurring specifically after upgrading to Pipelines 1.15.1, where issue occurs against an actual git repo. Testing here was done via tkn pac resolve` just to check overall resolver behavior, which tracks with the issue.

Acceptance criteria: 

PaC resolver either leaves the affected fields alone, or documentation is updated to reflect whether this behavior is expected.
 

Additional info (Such as Logs, Screenshots, etc):

N/A