Let a delegated task choose the workspace it runs in

delegate_task had no workspace argument: a task handed over from the
coordinator's own chat always ran in the worker's own chat, on that
worker's memory, files and directly assigned computers alone, even when
the work belonged to a workspace. The coordinator could not say where the
work goes, and the prompt never said the two differ.

- delegate_task takes an optional workspace_id: the worker runs the task
  in that workspace's context, with its own instructions and memory
  there, the project's files and the workspace's computers, and the
  result lands in its conversation in that workspace.
- A worker missing from that workspace is added first (pushBotCreated)
  and the reply says so.
- Handed over from inside a workspace the task always runs there; a
  different workspace_id is refused instead of ignored.
- The coordinator prompt, CoordinatorReplyNote and the tool description
  now spell the distinction out.

src/harness/tools/bot/grab-bot-chat-tools.ts

@@ -61,7 +61,9 @@ type Params = {
  * for the coordinator (the super admin's alone) create_workspace and
  * update_workspace (a workspace and its shared context), create_bot to
  * grow the crew, delegate_task to every worker (the workspace's in a
- * workspace) plus, in its own chat, find_bot and find_workspace,
+ * workspace, where the task runs; from its own chat, in the worker's own
+ * chat or in a workspace it names) plus, in its own chat, find_bot and
+ * find_workspace,
  * add_bot_to_workspace and remove_bot_from_workspace, assign_computer,
  * update_bot, delete_bot and delete_workspace (which workspace, which
  * computers, and which name, role and core instructions each crew member
@@ -150,6 +152,7 @@ export default async function grabBotChatTools({
             workspace_id,
             coordinator_name: bot.name || "The coordinator",
             workers,
+            workspaces,
         }),
     );