Delegate work to a background worker agent.

This is the only way to delegate. Use it for non-trivial work: multi-step tasks, investigations, code/file/browser workflows, or anything likely to need several tool calls. Keep trivial requests local.

The worker cannot see this conversation: it sees its own system prompt, `prompt`, `context_json` and its own history with you. A named agent keeps one history per chat: the earlier tasks you gave it and its answers, compacted when it grows. Pass `session` to keep a separate history with the same agent (for example one per client or thread); a general worker (no agent_name) only remembers when you give it a `session`, otherwise it starts empty. Tasks of the same agent and session run one at a time: a second one waits in the queue until the first finishes, so it sees that result. Use different sessions for work that should run in parallel. The worker can rely on its history, but any new fact it needs (texts, names, recipients, addresses, ids, results from other agents or from this conversation) must still go in `prompt` or `context_json`, written out in full. Never refer to "the conversation" or "what we discussed"; only to earlier tasks of this same worker and session.

Provide:
- prompt: clear, concrete worker instruction.
- agent_name: optional exact specialist agent name from the roster in your system prompt. Must match a
  registered agent's `name` exactly (check the roster or fetch_agent_info first) — an unknown name is
  rejected before the task is queued. Omit it to run a general worker agent.
- context_json: optional JSON object string the worker should receive as structured context.
- timeout_seconds: optional per-task budget, no greater than the configured worker timeout. Without it a
  named specialist uses its own configured timeout. The timeout is the only budget you set: steps and
  tool calls are bounded by configuration alone.
- model_provider, model, reasoning_effort: optional, for this task only. Use them when the request names a
  provider, model or thinking budget. Check fetch_agent_info for the providers that have credentials
  configured — an unconfigured provider is rejected before the task is queued.
- session: optional conversation name (letters, digits, `_`, `-`, `.`; max 64) for a separate history and queue with the same agent.
- fresh: optional boolean. True clears the history of this agent and session before the task, so it starts with no memory of earlier tasks. Use it when the task is unrelated to previous ones or the old history could mislead it; leave it unset to continue.
- continue_turn: optional boolean. Set it to true whenever a step remains after the result (indexing or verifying it, a dependent step, a comparison, a follow-up delegation): the result comes back to you as a new message with `metadata.source == "task_result"` and you answer from it. Set it to false only when the worker's answer is the final deliverable: it goes straight to the user, and only a short notice with the task id is kept in the history, so call get_task on the next user message if you need it. When unset, the configured default applies; the operator may force true for every task, ignoring your value. At most three continuing tasks per turn and three chained turns deep: past either limit an explicit true is rejected with `task:continuation_limit` (answer the user instead) and an unset value sends the answer straight to the user.

This returns a task_id immediately, not the answer: the worker runs asynchronously and its result, including any files it produced, reaches the same conversation as a later message (or as a new turn for you when continue_turn is true). Tell the user the work was handed off; never invent the outcome. Use get_task to retrieve it, list_tasks to see what is running, and cancel_task to stop one.
