Harness CI Build Pipeline: OIDC Connector

Migrate every Harness CI pipeline from static-credential cloud connectors to
OIDC-backed connectors.

For each repository containing `.harness/*.yaml` pipeline manifests:
1. Find every `connectorRef:` that points at a static-key connector
   (e.g., `aws_static_keys`, `gcp_service_account_key`, `azure_sp_secret`).
2. Rewrite each `connectorRef:` to the OIDC-backed equivalent using the supplied
   mapping (e.g., `aws_static_keys` → `aws_oidc`, `gcp_sa_key` → `gcp_oidc`,
   `azure_sp_secret` → `azure_oidc`).
3. Remove any `infrastructure.spec.connectorRef` overrides that hardcode the old
   credential connector at the step or stage level.
4. Remove stale `envVariables` entries that injected static credentials
   (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `GOOGLE_APPLICATION_CREDENTIALS_JSON`,
   `ARM_CLIENT_SECRET`), OIDC connectors handle this automatically.
5. Preserve `region`, `projectId`, `subscriptionId`, and all other non-credential fields.
6. Skip pipelines that already reference an OIDC connector.

In the PR body, emit the IAM trust policy snippet the cloud team needs to apply
(the AWS role's trust relationship, GCP Workload Identity binding, or Azure
federated credential), these changes are out-of-band.

The Problem

Harness CI pipelines historically authenticated to cloud providers using stored access keys. That means every pipeline needs a secret rotation policy, every secret leak is a long-lived credential incident, and key sprawl across pipelines is hard to audit.

OIDC connectors solve this: the pipeline exchanges a short-lived OIDC token for cloud credentials at run time. But rolling out OIDC means rewriting every pipeline’s `connectorRef`, deleting stale secrets, and updating IAM trust policies on the cloud side.

What Tidra Does

1. Finds every Harness pipeline manifest referencing a static-credential cloud connector
2. Rewrites the connectorRef to point at the OIDC-backed equivalent
3. Removes the stale infrastructure.spec.connectorRef overrides that hardcoded the old credential set
4. Generates the IAM trust policy snippet the cloud team needs to apply on the AWS/GCP/Azure side
5. Opens one PR per repo and a tracking issue listing IAM-side changes needed

Before & After

Customization Tips

• Connector inventory: Provide a mapping of old connectors → new OIDC connectors. Tidra applies it consistently.
• Multi-cloud: Works for AWS, GCP, and Azure connectors. Specify per-cloud target connectors in the prompt.
• IAM coordination: The IAM trust policy changes are out-of-band. Tidra emits the snippets but does not apply them.