fix: preserve task outputs across async batch flush

[greysonlalonde]

Fixes #4137. Replaces #4139 with regression tests added.

_process_async_tasks / _aprocess_async_tasks return a new list, so the six call sites that did task_outputs = self._process_async_tasks(...) were overwriting any sync outputs already accumulated. For [sync, async, sync] the leading sync output was silently dropped. The conditional handlers had a related issue: rebinding the task_outputs parameter discarded the async batch entirely.

Switches all six call sites from = to .extend(). Adds three regression tests covering the sync path, the native-async path (akickoff), and the conditional-task path. All three fail without the fix.

---

Note

Medium Risk
Touches core task-execution aggregation logic in both sync and native-async paths; a mistake could reorder or omit task outputs and affect downstream context/conditional behavior.

Overview
Fixes a regression where flushing pending async tasks (_process_async_tasks / _aprocess_async_tasks) could overwrite previously collected task_outputs, causing earlier sync outputs (and sometimes async outputs during conditional evaluation) to be dropped.

All affected call sites now append via task_outputs.extend(...) instead of rebinding the list, and new tests assert correct output preservation/order for mixed sync+async execution (kickoff), native async (akickoff), and when a ConditionalTask forces an async flush.

^{Reviewed by Cursor Bugbot for commit aa859ac. Bugbot is set up for automated code reviews on this repo. Configure here.}

[iris-clawd]

Classic = vs .extend() bug — rebinding the local task_outputs instead of appending to the existing list. All six call sites fixed consistently. Tests cover the three key scenarios (sync path, async path, conditional flush) and assert the output ordering is preserved.

LGTM ✅