* fix(orchestrator): keep task and session state in sync on tool-event wake
handleToolCallEvent and handleToolUpdateEvent woke the session from
WAITING_FOR_INPUT to RUNNING via updateTaskSessionState, but never
touched task.state. An out-of-turn tool event (e.g. a Monitor watcher
firing after on_turn_complete moved the task to REVIEW) left the task
parked in REVIEW while the session showed RUNNING — surfacing as a task
that "always works, never leaves state". Use setSessionRunning so
task.state flips to IN_PROGRESS in lockstep.
* fix(orchestrator): guard setSessionRunning against terminal sessions
Greptile flagged that setSessionRunning unconditionally wrote
tasks.state=IN_PROGRESS even when updateTaskSessionState silently
no-op'd because the session was already terminal. With the new
streaming-handler call sites, a buffered tool event arriving after
a CANCELLED/FAILED/COMPLETED session would leave the session
correctly terminal but flip the task back to IN_PROGRESS.
Resolve the session up front and short-circuit when terminal so
neither write fires. Add paired test sub-cases that pre-seed the
session as CANCELLED and assert the task state is not written.
---------
Co-authored-by: Kandev Agent <agent@kandev.dev>
João Salavisa
8ce989507a