Support zero-downtime main InstallerSet upgrades

Feature request

Main InstallerSet upgrades should use a readiness-gated handoff instead of deleting the current InstallerSets before creating their replacements.

Today, a release-version mismatch calls CleanupMainSet, and the old InstallerSet finalizers delete resources from the previous manifests before replacement sets are created:

• MainSet cleans up on ErrVersionDifferent
• TektonInstallerSet finalization deletes its manifest resources

This can temporarily remove shared ConfigMaps, RBAC, Services, APIService objects, and admission webhook configurations during an operator upgrade.

Implement a blue/green-style handoff for main InstallerSets:

1. Keep the current generation while creating the desired-generation static and workload InstallerSets.
2. Make replacement creation idempotent so reconciliation can resume after a partial failure.
3. Wait for all desired-generation InstallerSets to report Ready.
4. Retire only the explicitly identified old-generation InstallerSets.
5. During old-generation finalization, preserve resources also represented by a non-deleting successor InstallerSet and delete only resources absent from every successor.
6. Keep full cleanup when a component is removed and no successor exists.

The design should support the static/deployment split and the optional StatefulSet path without using broad CleanupMainSet selection during retirement.

Acceptance criteria:

• Shared resources remain available until the desired generation is Ready.
• Resources removed from the desired manifests are still pruned after a successful handoff.
• Interrupted replacement creation resumes without producing duplicate sets.
• Component deletion retains the existing cleanup behavior.
• Tests cover generation coexistence, readiness-gated retirement, partial creation, shared-resource preservation, and obsolete-resource deletion.

Related work: #374 introduced InstallerSets for pruning resources removed by new releases, and #2121 guards reconciliation when a resource is already being deleted.

Use case

An operator upgrade changes the main InstallerSet release version while Tekton components continue serving requests. The old and desired generations share resources such as configuration, admission registration, RBAC, and Services. Those resources must remain present until the desired generation is healthy; otherwise the upgrade can create an admission or service-availability gap even though the resources will be recreated later.

Start with MainSet and CleanupMainSet in pkg/reconciler/kubernetes/tektoninstallerset/client/main_set.go, then read TektonInstallerSet finalization in pkg/reconciler/kubernetes/tektoninstallerset/tektoninstallerset.go. Trace ErrVersionDifferent and the existing InstallerSet lifecycle before designing coexistence and readiness-gated retirement. Done means the listed coexistence, handoff, cleanup, idempotency, and resource-preservation cases are covered by tests.