feat(tasks): analyst opens the task; freestyle threads it into implementation

Two coupled gaps from tracing a real run:

1. Freestyle implements in phase 2 via stages compiled from the architect's
   execution_plan (ExecutionPlanCompiler sets allowedTools = stage.tools), so the
   static allow-lists never reach it and architect_freestyle.md banned every tool
   but the file four. Teach the architect to thread an analysis-referenced task
   through the plan: implementing stages get task_context/task_update and claim +
   submit_for_review; the final/review stage completes it. No task referenced → no
   task tools, and the plan never creates one.

2. Give the analyst task_create so the work is framed as a tracked item up front
   (role_pipeline + freestyle). "Read-only" for the analyst means it writes no
   files; a task is an event-log entry, not a file write — task_create is T2, so
   opening one is approval-gated. The analyst names the new id in the analysis so
   the implementer claims it and the reviewer completes it; the implementer now
   creates only as a fallback.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

examples/workflows/prompts/analyst_freestyle.md

@@ -4,7 +4,10 @@ given a directory path), `ls`, `grep`, `cat`, `find`.
 
 Before deriving requirements, check for existing work: `task_search` for related, duplicate, or
 blocking tasks and `task_context` to load any the goal names. Fold what you find into the
-analysis rather than re-deriving it; flag a duplicate instead of restating it.
+analysis rather than re-deriving it; flag a duplicate instead of restating it. If a task already
+covers this work, name its id (e.g. `auth-142`) in the analysis; if none does and the work
+warrants tracking (per the task policy), `task_create` one and name its id — either way later
+stages thread it through the plan.
 
 Emit the `analysis` artifact (JSON, schema provided):
 - `summary`: the goal in your own words.