Add task-level model and agent selection to workflows

[paullizer]

Summary

Add task-level model and agent selection to ordered workflow automation while retaining the workflow-level runner as the default. Each task can inherit the default, select an authorized direct model, or select an authorized personal/group/global agent.

User Value

Workflow authors can build deterministic sequential multi-agent automations, such as extracting facts with a fast model, enriching them with a tool-enabled agent, evaluating risks with a reasoning model, and publishing with a final agent.

Proposed Behavior

• Rename the workflow-level Runner field to Default Runner.
• Add per-task runner modes: inherit, model, and agent.
• Normalize and persist only server-authorized, non-secret model and agent summaries.
• Validate task runners on save and immediately before each task executes.
• Revalidate personal ownership, group membership/role, global-agent permission, model endpoint availability, and model availability at execution time.
• Dispatch task overrides through the existing sequential workflow model/agent/document execution path.
• Record non-secret requested/resolved runner metadata, attempts, status, timestamps, previews, execution model/provider details, and per-task token usage.
• Preserve legacy workflows, tasks without runner fields, retries, error strategy, cancellation, bounded handoff, document/File Sync/URL inputs, citations, artifacts, alerts, and aggregate token usage.

Acceptance Criteria

• Existing workflows use the renamed Default Runner without behavior changes.
• Existing tasks without runner configuration behave as inherit.
• Task model overrides persist normalized non-secret endpoint/model identifiers and execute with the selected authorized model.
• Personal and group task agent overrides persist normalized authorized identities and execute with current authorization.
• Cross-user, cross-group, stale, deleted, disabled, or unavailable task runners are rejected on save or fail at execution according to retry and error strategy.
• Sequential model -> agent -> model execution preserves handoff, inputs, cancellation, outputs, and aggregate accounting.
• Task run items contain complete non-secret runner audit metadata and per-task token usage where available.
• The stepped builder exposes responsive, accessible task runner controls, task-row summaries, and Review summaries with safe text rendering.
• Focused functional, access-control, syntax, diagnostics, XSS, and Azure Playwright coverage passes.
• Feature documentation, release notes, and application patch version are updated.

Out of Scope

• Parallel task execution.
• Conditional branching.
• Autonomous next-task selection.
• Graph orchestration.
• Cosmos migrations or new containers.

Notes

Builds on completed PR #1083 and associated issue #1082. Reuse the task sequence and dispatch implementation in functions_workflow_runner.py, functions_personal_workflows.py, and functions_group_workflows.py.

[paullizer]

Implementation is complete in PR #1085 (commit c9e170b3).

Implemented:

• Per-task Workflow default, Direct Model, and Agent runner selection for personal and group workflows.
• Server-side normalization on save and execution-time revalidation of current agent/model availability and group role.
• Temporary task bindings through the existing sequential dispatch path, with retries and stop/continue behavior for unavailable runners.
• Non-secret task runner audit metadata, execution deployment/provider, output preview, attempts/timestamps, and per-task token usage when available.
• Shared stepped-builder controls, task-row and Review summaries, responsive behavior, safe text rendering, version 0.250.065, feature docs, and release notes.

Validation:

• 23 focused workflow tests passed.
• Python and JavaScript syntax checks passed.
• Editor diagnostics and git diff --check passed.
• Revision-scoped XSS guardrail passed for 6 files.
• Revision-scoped broken-access-control guardrail passed for 3 Python files.
• Azure Playwright task-runner coverage was added; local execution skipped because no authenticated UI target/storage state was available.
• Existing cancellation contract has one unrelated stale v0.250.062 assertion already present on Development.