refactor(label-list): let the label docks own their own recoloring

Decision needed

Decide whether dock-owned recoloring now provides enough locality to justify a refactor. Revalidated against main at 1c6b807d: Qt now draws label text through a shared color-dot delegate. The earlier proposal to rebuild HTML/color-dot text is stale. The window still reads the Label List item role and updates cached colors, but it also uses that item role for label validation; moving recoloring alone would not remove that broader knowledge. No incorrect recoloring behavior was verified in this architecture scan.

What to build, if selected

Let the Label List and Shape List modules refresh their own cached colors through a color-resolver interface. Keep visible labels, Group and Shape Flag text, selection, visibility, ordering, and immediate Settings application unchanged. Reuse the existing Qt delegate and role storage.

Acceptance criteria

• A Shape Color Setting change recolors both lists and the canvas immediately.
• Recoloring in the window no longer reads or writes item-role storage or formats Shape text.
• Existing label-edit and label-add paths are reviewed together so this does not introduce a second formatting owner.
• Tests verify colors, text, selection, visibility, and ordering through the dock interfaces; desktop QA confirms the visible result.

Recommendation and tradeoff

Worth exploring, with medium confidence. Qt’s model/view guidance supports concentrating presentation knowledge, but does not establish a need for another interface here. The concrete inference/rendering separation and Qt-free text proposal work had clearer payoff. This remains a maintainer scope decision, not a verified defect or a blocker for those PRs.

Blocked by

None. The previous prerequisite has landed.