proposal: support scheduled CronJob workloads

[atkrad]

Problem

#17 covers one-shot Kubernetes Jobs (role: job). Many batch workloads need a schedule (nightly cleanup, reports). The Deployah chart already has CronJob scaffolding, but nothing maps a first-class schedule into a deployable CronJob, and #17 explicitly keeps CronJob out of scope.

Goals

• Spec can express a scheduled job that renders a Kubernetes CronJob.
• Reuse job container fields (image, command/args, resources, profiles) from the job path.
• Platform/plan/scenarios cover CronJob manifests.
• Clear validation for cron schedule and concurrency policy.
• Link cleanly to proposal: support role: job workloads #17 (one-shot Job) without merging the two product surfaces.

Non-goals

• One-shot Job / migrate-on-deploy hooks (proposal: support role: job workloads #17).
• Full workflow engines (Argo, Tekton).
• Replacing platform cron operators outside Deployah.

Proposed design

User experience

Either extend role: job with a schedule field, or keep schedule as the CronJob discriminator:

components:
  cleanup:
    image: ghcr.io/acme/cleanup:${TAG}
    role: job
    job:
      schedule: "0 3 * * *"
      concurrencyPolicy: Forbid    # optional
      # successfulJobsHistoryLimit / failedJobsHistoryLimit optional
    resourcePreset: small

Rule of thumb (align with #17):

• No schedule → Job (proposal: support role: job workloads #17)
• schedule set → CronJob (this issue)

Wire the chart CronJob template to the main component image/command/resources path (today it is a stub expecting hand-built cronjob.containers).

Behavior

1. Validate cron expression and job/CronJob-incompatible fields (expose, health, autoscaling).
2. Emit CronJob; no Deployment/Service/Ingress/HPA.
3. Capability/docs: cluster must support batch/v1 CronJob (standard).

Alternatives considered

1. Fold into proposal: support role: job workloads #17. Rejected earlier; different lifecycle and UX.
2. New role: cron. Clearer controller name; more roles to teach. Prefer job.schedule unless review prefers a new role.
3. Extras-only CronJob. Escape hatch; leaves chart scaffolding unused.

Compatibility and migration

• Depends on / follows proposal: support role: job workloads #17 patterns (validation, no service ports).
• Related: proposal: support role: worker workloads #18 (workers are long-running, not scheduled), proposal: support KEDA event-driven autoscaling #25 (KEDA cron scaler is different).

Test plan

• Unit: schedule present → CronJob values; invalid cron → error
• Scenario: expected CronJob manifest
• Docs: Job vs CronJob; link from proposal: support role: job workloads #17

Checklist

• I searched existing issues and discussions
• This includes enough design detail for implementation (not only a wish)