feat: Let the AI see and set task colours

[camielvs]

Description

Colour is how people group tasks on a canvas by eye — often into stages that were never
made into subgraphs. None of it reached the assistant, so it would describe a pipeline
while blind to the structure the user had encoded into it, and had no way to colour
anything itself.

A task's colour now appears in what the assistant reads, and only once someone has set
one: an uncoloured task says nothing rather than reporting the transparent default.
set_task_color recolours any number of tasks in one call, including tasks in different
subgraphs, since colour is a per-task annotation with no reference to its graph. Colours
are restricted to the values the picker can produce, and nothing is written unless every
id and the colour are valid.

The prompts treat colour the way they treat sticky notes — the user's own mark, not the
assistant's to change unasked. The architect is also told that existing colour grouping is
information rather than decoration: tasks sharing a colour are one stage in the user's
head, which is usually what a subgraph should follow. Repair is told plainly never to
recolour a task to flag it as broken or fixed.

Named set_task_color to match the existing TASK_COLOR_ANNOTATION and
batchSetTaskColor; the prose keeps the repo's British spelling as its comments already
do.

Related Issue and Pull requests

Top of the five-PR stack. Shares the colour validation added in the sticky-notes PR at
the bottom.

Type of Change

• New feature

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Test Instructions

1. Colour three steps by hand, then ask the assistant what the pipeline looks like — it
   should notice the grouping rather than describing every step as identical.
2. Ask it to colour a group of steps — they should all get the same colour in one undo
   step.
3. Ask it to colour steps that live in different subgraphs in one request — it should
   handle both.
4. Ask it to clear a step's colour — it should go back to the default card, and the
   annotation should be gone rather than set to "transparent".
5. Ask for an off-palette colour — it should explain and offer the swatches.
6. Ask it to colour a set where one id is wrong — nothing should change, and it should say
   which id it could not find.
7. Colour a group of steps, then ask it to group them into a subgraph without naming which
   — it should follow your colour grouping.
8. Ask it to fix validation issues — it should not recolour anything to mark progress.
9. In the run view, ask it to colour a step — read-only message.

🤖 Generated with Claude Code

[github-actions]

🎩 Preview

A preview build has been created at: ai-task-colours/619a670

[camielvs]

Correctness pass over the branch (diff against ai-pipeline-notes). No findings — this one is clean.

Ran it in a throwaway worktree: tsc --noEmit clean, eslint clean on all five changed source files, and the full Vitest suite green (234 files / 2538 tests), including the 121 tests in the two touched test files.

What I checked, and why each candidate concern turned out not to be a bug:

• setTaskColor handler — validates the colour, rejects an empty id list, and resolves every $id via resolveTarget before calling batchSetTaskColor, so a bad id genuinely cannot produce a partial write. Dedupes with a Set. No await between resolution and mutation, so it does not need the root-pinning guard addTask has.
• Cross-subgraph mutation — locateEntity recurses through task.subgraphSpec, which is a real prop<ComponentSpec> in the keystone tree, and undo.init(rootSpec, …) (useSpecLifecycle.ts:45) anchors the undo manager at the root. So nested colour edits are recorded, undoable and serialized (jsonSerializer.ts:127 emits task annotations).
• transparent round-trip — the annotation codec defaults to "transparent", so Annotations.get never returns undefined; serializeTask maps the sentinel to undefined and pickDefined drops it, matching batchSetTaskColor's remove() on "transparent". No path gets a stale "transparent" into the AI payload. (Worth noting this is the one place in the stack where the codec-default-is-not-undefined pattern is handled correctly — see the (0,0) position findings on #2766 and #2767 for the same pattern going wrong.)
• Colour validation — isPickableColor accepts 3- and 6-digit hex, and parseHexToRgb in TaskNode/color.utils.ts handles both, so an AI-set #abc cannot produce NaN in the palette/contrast maths.
• Interface fan-out — both ToolBridgeApi implementors (editor csomBridge, runViewToolBridge read-only stub) were updated. No other registry enumerates tool names except TOOL_STATUS_LABELS, which has a "Working..." fallback and already omits several sibling tools.
• Colour survives create_subgraph (the behaviour the new architect prompt steers toward) — snapshotTask clones annotations.items and rebuilds with Annotations.from(...) correctly.