feat: 添加标签颜色功能并更新相关组件和测试用例

docs/adr.md

@@ -338,3 +338,47 @@ ADR-007 明确否决了「批量改属性做 `[{id, before}]` 快照式撤销」
   `resetHistory()`，避免「打开页面就能撤销一次数据清理」。
 - ADR-007 中「_批量改属性不做撤销_」一条作废；其余结论（软删除、`activeTasks` 单一剔除点、
   标签增删语义）不变。
+
+---
+
+## ADR-011 · 标签颜色独立存储，不进入任务数据
+
+**背景**
+
+「已知限制」里长期挂着一条「标签还没有颜色」。标签是纯字符串，在卡片上与优先级、截止日期挤在同一行，
+标签一多就难以扫读，上色是最直接的缓解手段，成本也远低于子任务、多设备同步这类结构性改动。
+
+真正的决策点不是「怎么上色」，而是**颜色存在哪里**：放进 `PersistedState`（跟随导出、快照、导入），
+还是单独一个 localStorage 键。
+
+**结论**
+
+1. 颜色存独立的 `kanban.tagColors`，结构为 `{ [tag: string]: 色板id }`，**不进 `PersistedState`**，
+   因此 `schemaVersion` 保持 3，不需要任何迁移。
+2. 存的是**色板 id**（`rose` / `sky` / …）而不是 class 字符串。以后调整视觉样式只改代码，不用动用户数据。
+3. 色板固定 8 色，每个色板在源码里写**完整类名字符串**。Tailwind v4 构建时扫描源码，
+   动态拼接的 `bg-${color}-500` 不会被生成，样式会静默失效 —— 这是这个功能唯一的硬坑。
+4. **未设置颜色的标签不画圆点**，也不在映射里占位。默认给每个标签一个灰点只是把噪音放大，等于没上色。
+5. 标签治理（重命名 / 合并 / 删除）在 `stores/tasks.ts` 的三个方法里顺带调用颜色 store，
+   把颜色的键名一起搬走。放在这里而不是面板组件里，是为了以后新增一种治理操作时不会漏掉颜色迁移。
+6. 目标标签已经有颜色时**保留目标的**：那是用户为它单独设过的，来源方更像「顺手被并过来」的一方。
+7. 读写失败静默降级（隐私模式 / 配额满）。颜色丢了不影响任何任务，不值得弹告警打断使用。
+
+**被否决的方案**
+
+- _放进 `PersistedState`，跟随导出与快照_：好处是换设备能带走。代价是导入语义变浑 ——
+  覆盖导入会变成「连别人的审美一起覆盖」，合并导入又该不该合并颜色？为了让导出多带几个键，
+  引入一套「导入时忽略某字段」的特例，不划算。而且颜色是**可重建的**，任务不是。
+- _允许任意取色器_：会带来对比度失控（深色模式尤甚）、需要对存储值额外校验，以及一堆无法被
+  Tailwind 静态扫描的动态类名。8 个手挑的色板足够区分，每档都验证过明暗两套主题。
+- _卡片上用整块 chip 背景着色_：标签行与优先级、截止日期共处一行，加背景色会把行撑高，
+  也会与「红色 = 逾期」的语义打架。改成小圆点 + 文字保持中性，既区分了标签，又不干扰紧急度判断。
+
+**影响**
+
+- 新增 `src/utils/tagColors.ts`（纯逻辑）与 `src/stores/tagColors.ts`（持久化），共 41 个单测。
+- `TaskCard` / `TagFilter` / `TagManagerPanel` 三处消费颜色；前两者改为依赖 store，
+  因此对应组件测试需要 `setActivePinia`。
+- 标签圆点带 `data-role="tag-dot"`：卡片上本来就有别的圆点元素（状态点、勾选框），
+  用 `.rounded-full` 这类样式选择器会误伤，单测与 e2e 一律按 `data-role` 定位。
+- 导出 JSON 不含颜色，README 的已知限制已写明。