feat: add parent-child task relationship API and env var injection

[knechtionscoding]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Adds the foundational API types and controller logic for parent-child task relationships, enabling agents to dynamically spawn child tasks at runtime (Phase 1 of #829).

Changes:

1. API additions (api/v1alpha1/task_types.go):

   • TaskSpec.ParentRef — optional reference to the parent Task that spawned this child (immutable via existing spec-level CEL rule)
   • TaskStatus.ChildTasks — list of child task names and their current phases
   • TaskReference and ChildTaskStatus supporting types

2. Env var injection (internal/controller/job_builder.go):

   • KELOS_TASK_NAME and KELOS_TASK_NAMESPACE are now injected into all agent containers, providing identity context for the upcoming kelos-mcp-server binary

3. Controller child tracking (internal/controller/task_controller.go):

   • updateParentChildStatus() — updates parent's status.childTasks when a child task's phase changes (with conflict retry for concurrent children)
   • enqueueParentTask() watch — ensures child task phase changes trigger reconciliation
   • Parent-not-found is handled gracefully (no error)

4. Tests:

   • Env var injection test for KELOS_TASK_NAME / KELOS_TASK_NAMESPACE
   • updateParentChildStatus happy path and parent-not-found cases

Which issue(s) this PR is related to:

Partial implementation of #829

Special notes for your reviewer:

• ParentRef immutability is enforced by the existing self == oldSelf CEL validation on the entire Task.Spec — no additional rule needed.
• The enqueueParentTask watch enqueues the child itself (not the parent directly) so that the child's reconcile loop handles the parent status update. This avoids needing a field index on spec.parentRef.name for now.
• This PR is backward compatible: both new fields are optional and existing Tasks are unaffected.
• Follow-up PRs: kelos-mcp-server binary (PR 2), RBAC auto-creation (PR 3), agent image integration (PR 4).
• This is a separate PR from the rest to align on the API definition

Does this PR introduce a user-facing change?

Add parent-child task relationship support: Tasks can now reference a parent via `spec.parentRef`, and parent Tasks track child phases in `status.childTasks`. Agent pods receive `KELOS_TASK_NAME` and `KELOS_TASK_NAMESPACE` environment variables.

---

Summary by cubic

Add parent–child task support so agents can spawn child tasks at runtime and parents track their phases, plus inject task identity env vars into agent containers. Adds a Parent print column to the Task CRD for quick kubectl visibility; Phase 1 of #829.

• New Features
  • API: spec.parentRef to reference a parent task; status.childTasks to list children and their phases; both optional and backward compatible.
  • Controller: updates parent status.childTasks on child phase changes, removes entries when children are deleted, retries on conflicts, and ignores missing parents.
  • Env: inject KELOS_TASK_NAME and KELOS_TASK_NAMESPACE into all agent containers.
  • CRD: add a "Parent" print column showing .spec.parentRef.name in both chart and install manifests.

^{Written for commit 339a3bd. Summary will update on new commits.}

[knechtionscoding]

@gjkim42 figured I'd give you a second core API change to review over the weekend. We are interested in being able to spawn sub agents, so wanted to put this up and get feedback before I go to deep

[cubic-dev-ai]

1 issue found across 9 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[knechtionscoding]

API Design Review

Verdict: APPROVE
Scope: New spec.parentRef (TaskReference) and status.childTasks ([]ChildTaskStatus) fields for parent-child task relationships; KELOS_TASK_NAME/KELOS_TASK_NAMESPACE env var injection

Findings

API Conventions ✅

• TaskReference follows the established pattern of SecretReference, WorkspaceReference, and AgentConfigReference — single Name field for same-namespace references.
• ParentRef is correctly a pointer type with +optional and omitempty.
• ChildTasks uses +listType=map / +listMapKey=name (lines 341-342), consistent with other list fields in this file (lines 168-169, 191-192). This ensures correct SSA merge semantics.
• Field names are camelCase in both Go and JSON tags. ✅
• No boolean fields with isX/enableX prefixes. ✅

Compatibility ✅

• All new fields are additive and optional — existing manifests apply without modification.
• ParentRef immutability is correctly covered by the existing self == oldSelf CEL rule on Task.Spec (line 361).
• No scalar↔array kind changes, no tightened validation on existing fields.
• No stale manifests in examples/ or self-development/ to sweep (new fields are optional; existing YAMLs remain valid).
• Generated deepcopy and CRD YAML artifacts are included. ✅

Naming and Documentation ✅

• parentRef / TaskReference follows the xxxRef / XxxReference naming convention established by workspaceRef, secretRef, agentConfigRef.
• childTasks (plural list in status) with ChildTaskStatus item type is clear and descriptive.
• Godoc comments present on all exported types and fields.
• The TaskReference type name is correct given it references a Task. If other CRDs later need to reference Tasks, this type is reusable.

Validation ✅

• TaskReference.Name has +kubebuilder:validation:MinLength=1 — actually better than the existing SecretReference and WorkspaceReference which lack this marker.
• ChildTaskStatus.Name is in the required list in the generated CRD (appropriate since it's the listMapKey).

Extensibility ✅

• TaskReference is a struct (not a bare string), allowing future extension with fields like namespace if cross-namespace parent references are ever needed.
• ChildTaskStatus is a struct that can grow additional fields (e.g., message, startTime, aggregated results per issue #829 Phase 4).
• The API surface is minimal — only the fields immediately needed for Phase 1. No speculative additions.

Suggestions (non-blocking)

• ChildTaskStatus.Name MinLength: Consider adding +kubebuilder:validation:MinLength=1 to ChildTaskStatus.Name (api/v1alpha1/task_types.go:296) for consistency with TaskReference.Name. Since this field is controller-managed it won't reject user input, but it documents the invariant and prevents accidental empty keys in the list map.
• Stale child entries: The controller currently only adds/updates entries in status.childTasks but never removes them when a child Task is deleted. This means a deleted child will persist in the parent's status with its last known phase. For Phase 1 this is acceptable (the data is observational, not prescriptive), but worth noting for a follow-up to garbage-collect entries referencing deleted Tasks.

/kelos needs-input