--migrate: Kubernetes Job manifest (dotCMS/platform) + docs/ci-cd.md runbook entry

Part of #37237. Cross-repo — the Job manifest itself lives in dotCMS/platform, tracked here as one deliverable alongside the runbook entry in dotCMS/dot-ca-event-manager. Doesn't block the other sub-tickets and can land whenever.

Summary

The concrete way an operator actually runs --migrate in production: a one-off Kubernetes Job, never an exec into a running pod — and the runbook step that documents when to trigger it.

Scope

1. Kubernetes Job manifest — dotCMS/platform
Same image and the same admin ClickHouse credentials/secrets as CAEM's existing Deployment (kubernetes/clusters/*/workloads/ca-event-manager/). Its own dedicated pod, so it can never collide with one serving live traffic. Success/failure visible via kubectl get jobs/pod logs — this is what the Core migration engine ticket's exit codes/summary block feeds.

2. docs/ci-cd.md runbook entry — dotCMS/dot-ca-event-manager
The operator-run step that triggers the Job, placed before the app-image-promotion step in the existing manual production promotion procedure (mirroring how the runbook already documents the operator running manual docker/aws ecr commands for image promotion).

Why a Job, not an exec

An ad hoc exec session into a running pod guarantees none of: an isolated pod (risk of colliding with live traffic), a clean image/credential match with the Deployment, or durable success/failure visibility. A Job gives all three for free.

Note

This ticket likely needs a dotCMS/platform owner in addition to whoever picks up the dot-ca-event-manager runbook half.

Repos

dotCMS/platform, dotCMS/dot-ca-event-manager

Start with the existing Deployment under kubernetes/clusters/*/workloads/ca-event-manager/ in dotCMS/platform and the manual production promotion procedure in docs/ci-cd.md in dotCMS/dot-ca-event-manager. Confirm how the Job should reuse the Deployment image and admin ClickHouse credentials, then place its runbook step before app-image promotion. Done means both repositories contain the manifest and operator instructions, with Job status and pod logs providing success or failure visibility.