Bug: Pausing a workflow does not pause/cancel its running jobs

Bug Description

When a workflow is paused, its currently running jobs (crawls, search jobs) continue to execute instead of being cancelled or paused.

Expected Behavior

When a user pauses a workflow:

1. Any running workflow executions should be cancelled
2. Any running step executions (crawls, search jobs) associated with the workflow should be cancelled
3. Reserved credits for running operations should be released

Current Behavior

The workflow status is set to paused, but:

• Running workflow executions continue until timeout
• Running crawls and search jobs spawned by the workflow continue executing
• Credits remain reserved until operations complete or timeout

Reproduction Steps

1. Create a multi-step workflow with search and crawl steps
2. Execute the workflow
3. While the workflow is executing, pause it via API or dashboard
4. Observe that the underlying crawls/search jobs continue to run

Impact

• Users who pause a workflow to stop it immediately have to wait for operations to timeout
• Credits remain consumed for unwanted operations
• Workflow execution history shows misleading "failed due to timeout" rather than "cancelled"

Proposed Solution

In the workflow pause handler (PATCH /api/v1/workflows/{id} or equivalent):

1. When status is changed to paused:

• Query for any running or pending workflow_executions for this workflow
• For each running execution:
• Query workflow_step_executions in running/pending status
• Cancel associated crawls via DELETE /api/v1/crawls/{id} or direct status update
• Abort associated search jobs via POST /api/v1/search/jobs/{id}/abort
• Update step execution status to cancelled
• Update workflow execution status to cancelled
• Release any reserved credits

Files Likely Affected

• app/api/v1/workflows/[id]/route.ts (PATCH handler)
• lib/workflow/executor.ts (or equivalent execution logic)
• Possibly need new cancellation helpers in lib/workflow/

Additional Context

Observed on workflow 2d7d006b-b899-48b1-83e1-680fd21fac3a which was paused at 10:48 UTC but had executions that ran until 11:41 UTC (timeout).