Add true cancellation for active workflow runs

[paullizer]

Summary

Add a true cancellation capability for active SimpleChat workflow runs. Users should be able to cancel a personal or group workflow run and have execution actually stop, rather than only marking the run as cancelled while the runner continues best-effort work in the background.

User Value

Long-running workflows can consume model capacity, Cosmos throughput, downstream API quotas, and user attention. A real cancel control gives users and admins a reliable way to stop accidental, stale, or runaway workflow executions before they continue through document analysis, tool/action loops, File Sync pre-run work, URL access, generated artifacts, or model/agent calls.

Proposed Behavior

Expose a cancel action for active workflow runs across personal and group workflows. When cancellation is accepted, the active runner must stop the run control flow, release the workflow run lock, move the run and any remaining work to a terminal cancelled state, and prevent further workflow steps or output writes for that run.

This is not complete if the implementation only updates UI/status records while the existing runner continues executing. The cancellation request needs to be part of the runner contract, with cancellation checks or cancellation tokens at the boundaries that can start meaningful additional work.

Relevant current surfaces:

• Personal workflow manual runs: POST /api/user/workflows/<workflow_id>/run
• Group workflow manual runs: POST /api/group/workflows/<workflow_id>/run
• Run history and resume-failed endpoints already exist for personal and group workflows.
• Workflow activity already streams live run state and should reflect cancellation progress and terminal cancelled state.

Acceptance Criteria

• Active personal workflow runs expose a cancel API and UI control from the run/history/activity surfaces.
• Active group workflow runs expose an equivalent cancel API and UI control with existing group membership and workflow permission checks.
• Cancellation is persisted by workflow scope and run id so any worker handling the run can observe it.
• The workflow runner stops after cancellation is requested and does not begin additional File Sync, URL access, document-analysis, model, agent, tool/action, artifact, or notification work for the cancelled run.
• The run record, workflow runtime fields, workflow activity stream, and per-item status records consistently report cancelled for cancelled work.
• Workflow locks are released and the workflow returns to an idle/schedulable state after cancellation handling completes.
• Scheduled and File Sync-triggered workflows do not immediately restart the same cancelled run as a retry, and future scheduled runs still work normally.
• The UI disables or hides cancel once a run reaches a terminal state and clearly shows that the run was cancelled.
• Functional tests cover personal cancellation, group cancellation, permission boundaries, run/item state transitions, and lock release.
• Documentation or release notes describe the user-visible cancel behavior once implemented.

Notes

This likely touches route_backend_workflows.py, functions_workflow_runner.py, personal/group workflow storage helpers, workspace/group workflow UI, workflow activity streaming, and workflow functional/UI tests.