delete_workflow MCP tool can't reach force=true, and its own error message describes an impossible step

**Reason:** `DELETE /api/workflows/{workflowId}` already supports `?force=true` to cascade-delete
a workflow that has execution history (soft-delete the workflow, hard-delete step logs, soft-
delete executions, drop schedules — added under KEEP-440). But the `delete_workflow` MCP tool
(`lib/mcp/tools.ts`) has no `force` argument at all, and when it hits the 409 from
`hasExecutions && !force`, the response text says *"Workflow has execution history. Delete
executions first before deleting the workflow."* (`app/api/workflows/[workflowId]/route.ts:926`
and `:1009` on `staging`). There is no tool, MCP or otherwise, that lets an MCP caller delete
individual executions — the instruction describes a step that doesn't exist. An MCP-only caller
that hits this message has no way to satisfy it and no way to reach `force=true`, since that's a
query param on a REST route it never touches directly. What told me to expect this to work: the
error message itself states a concrete next step ("delete executions first"), which implies a
recovery path exists; it doesn't.

Confirmed still present on `staging` @ `f70b73bc9630`: `lib/mcp/tools.ts` has no `force` parameter
on `delete_workflow` (searched, zero matches), and the 409 message at both call sites in
`app/api/workflows/[workflowId]/route.ts` is unchanged.

**Scope:** `lib/mcp/tools.ts`'s `delete_workflow` tool definition, plus the two 409 message
strings in `app/api/workflows/[workflowId]/route.ts`. The `force=true` cascade logic itself is
pre-existing and untouched — this is purely about exposing the existing REST capability to the
MCP tool and fixing the message so it points at something a caller can actually do. Checked: the
access-control path (`validateWorkflowAccess`, `requireScope(SCOPE_MCP_WRITE)`) is unrelated and
unaffected. Not in scope, flagging for awareness only: `force` currently has no execution-status
filter, so it applies identically to in-flight and completed executions — that's existing route
behavior this issue doesn't change, just makes reachable from MCP too. Worth its own discussion
if the team wants to scope `force` down before agents (not just human REST callers) can trigger
it on running executions.

**Plan:** Add an optional `force: boolean` argument to `delete_workflow` in `lib/mcp/tools.ts`,
forwarded as `?force=true` on the underlying DELETE call when true (omitted/false leaves today's
behavior unchanged). Update both 409 message strings to say `force=true` instead of the impossible
"delete executions first" step. I already have this implemented with 3 unit tests pinning the
exact query string for omitted/false/true, plus a docs update to the `delete_workflow` table row
— happy to open the PR once this is accepted.

Start with the delete_workflow definition in lib/mcp/tools.ts and the two 409 response strings in app/api/workflows/[workflowId]/route.ts. Run the MCP unit tests, including coverage for omitted, false, and true force values. Done means force=true reaches the DELETE query, the default behavior is unchanged, both messages describe the available recovery path, and the delete_workflow documentation row is updated.

Written by the indexing model from the issue text.