Expose nodeSelector configuration for operator-managed Jobs (migration, reset-admin-password, update-content-checksums)

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

Today the Pulp CRD exposes node_selector for long-running components such as api, content, worker, web, cache, and database, but it does not provide a way to configure pod placement for some Kubernetes Jobs created by the operator.

In particular, there is currently no obvious CRD field to control the nodeSelector used by these Jobs:

• pulp-pulpcore-migration-*
• pulp-reset-admin-password-*
• pulp-update-content-checksums-*

This makes it difficult to run all Pulp-managed workloads on the appropriate node pool when clusters are segmented by node role, cost profile, security constraints, or storage/network locality. In those environments, the Jobs may need to run on the same class of nodes as the rest of the Pulp workloads.

Describe the solution you'd like

Please expose nodeSelector configuration in the Pulp CRD for the Jobs created by the operator, specifically for:

• migration Jobs
• reset-admin-password Jobs
• update-content-checksums Jobs

Ideally this would allow users to define scheduling constraints for those Jobs in the same declarative way they can already do for other Pulp-managed workloads.

One possible approach would be to add dedicated CRD sections/fields for these Jobs, for example:

• spec.migration_job.node_selector
• spec.admin_password_job.node_selector
• spec.update_content_checksums_job.node_selector

If the project prefers a different naming convention, any equivalent mechanism to configure the Job pod nodeSelector through the CR would solve the problem.

Describe alternatives you've considered

• Manually patching the generated Jobs after they are created. This is fragile and likely to be overwritten by reconciliation.
• Relying only on cluster-wide defaults. This is not always possible in shared clusters with multiple node pools.
• Using existing component-level node_selector fields such as worker.node_selector. This does not appear to cover these one-shot Jobs explicitly.

Additional context

I looked for existing support and found that the repository already includes node_selector support for several pod-based components, but not an obvious equivalent for these Jobs.

The relevant Job names in the codebase are:

• pulpcore-migration-
• reset-admin-password-
• update-content-checksums-

Having this configurable in the CRD would improve consistency with the rest of the operator and make scheduling behavior easier to control in production Kubernetes environments.

Start by locating the operator reconciliation or job-generation entry points for pulpcore-migration-, reset-admin-password-, and update-content-checksums-, then compare them with existing component node_selector handling and the CRD schema. Done means the CRD provides a consistent selector configuration for all three Jobs and the generated Job pods use it.