fix(operator): stamp apply ErrorMessage from the aggregate failure

[Kiran01bm]

What

When the operator re-derives a parent apply's state from its apply_operations rows and the rollout settles to failed, the apply's ErrorMessage is now surfaced from the aggregate — the first failed operation — instead of whatever message the last-driven operation left behind.

Why

The bug: updateApplyStateFromOperations re-derives applies.state from the operation rows but copies the apply struct verbatim and never touches ErrorMessage. So the failure reason is whatever the last operation to write the apply happened to leave. Under on_failure: continue the rollout keeps driving siblings past a failed deployment, so the last driver is frequently a successful sibling — leaving the apply with a failed verdict and an empty or misleading reason. An operator triaging the failure sees the verdict but not why.

The fix: when the derived state is failed, stamp ErrorMessage from the first failed operation row (deployment order), formatted as deployment <name> failed: <reason>. The rollout's verdict is the first failure, so the first failed row wins. If no failed operation carries a message, the existing apply message is kept as a fallback rather than blanked.

Operation rows already carry their own correct failure message (each operation is persisted from its own tasks), so the aggregate has the right data to surface.

ops: [region-a failed "cutover failed", region-b completed] ─▶ derived = failed
└▶ apply.ErrorMessage = "deployment region-a failed: cutover failed"
(not region-b's empty / last-op message)

Notes

Stacked on #343 (operation-state-first persistence) — review/merge that first. Scoped to the operator's aggregate writer; the tern per-op stamping and single-writer refactor are separate follow-ups.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.