fix(agent): install a colour palette in one mutation, not one per token

[DavidBabinec]

Summary

site_set_color_tokens could report a successful batch update even when only part of the batch was persisted. This change makes palette updates atomic at the editor-store mutation boundary and turns refused writes into explicit errors.

Root cause

runSetColorTokens previously called createFrameworkColorToken once per token. Each call performed its own mutateSite, while collaboration document binding could temporarily mark the site as not writable during the same synchronous batch. Later writes were then refused as syncing.

The failure was silent because the per-token action returned a token without checking whether mutateSite accepted the write, and the runner reported every requested token as created.

Changes

• Add upsertFrameworkColorTokens to create or update an entire color-token batch in one site mutation.
• Plan slugs and category labels against the growing batch so in-batch uniqueness matches sequential updates.
• Return an accepted result and fail the tool call when the collaboration gate refuses the batch.
• Make the font-token, type-scale, and spacing-scale tool paths verify their writes instead of reporting unpersisted values as successful.

Verification

Added src/__tests__/collab/paletteBurstWrite.test.ts covering:

• a multi-token palette is stored in one mutation
• slugs remain unique within a batch
• repeated updates modify existing tokens instead of creating suffixed duplicates
• a refused batch returns ok: false and stores nothing

Full test suite: 6461 passing, 0 failing.