Standardize theme palette precedence across diagram types

Summary

Standardize how DiagramForge chooses colors for repeated visual elements across diagram types so theme behavior is predictable and consistent.

This is a follow-up to the Target Diagram work and should stay out of the Target Diagram PR itself.

Problem

DiagramForge currently has a clear distinction between:

• semantic theme colors such as PrimaryColor, SecondaryColor, and AccentColor
• repeated-element palettes such as NodePalette / NodeStrokePalette

But that distinction is not applied consistently across diagram types.

Examples:

• generic node rendering prefers NodePalette when present
• snake layout assigns circle colors from NodePalette
• Target ring colors derive a custom set from semantic theme colors plus NodePalette
• XY chart series colors currently derive a separate palette from AccentColor and related theme colors rather than preferring NodePalette

The result is that a theme can look coherent in one diagram kind and behave differently in another, even when the caller expects the palette to be the main source of repeated colors.

Goal

Make DiagramForge theme behavior more standard and predictable by defining a single precedence model for repeated colors.

Recommended direction:

1. Semantic theme colors define overall theme identity.
2. NodePalette defines the default color cycle for repeated visual elements.
3. Diagram-specific derivation should happen only when needed, and only as an explicit extension of the palette model.
4. When no palette is present, diagram types may derive a small fallback cycle from semantic colors.

Scope

In scope:

• define precedence rules for repeated-element colors
• document whether repeated elements should prefer NodePalette first
• align XY chart series color selection with the same rules used by other diagram kinds where appropriate
• review Target and snake behavior against the standard rules
• update docs for theme semantics vs palette semantics
• add focused tests that lock the precedence model down

Out of scope:

• redesigning all built-in themes
• introducing new public theme models or breaking changes unless clearly justified
• broad visual redesign work unrelated to color-selection rules

Recommended implementation direction

Create and document a standard precedence order such as:

1. explicit element color override
2. diagram-specific explicit palette override
3. Theme.NodePalette / Theme.NodeStrokePalette
4. derived fallback from semantic theme colors
5. legacy single-fill fallback (NodeFillColor / NodeStrokeColor)

The exact order can be refined during implementation, but the important part is that it is shared and documented.

Candidate files

• src/DiagramForge/Models/Theme.cs
• src/DiagramForge/Rendering/SvgNodeWriter.cs
• src/DiagramForge/Rendering/SvgRenderSupport.cs
• src/DiagramForge/Layout/DefaultLayoutEngine.Snake.cs
• src/DiagramForge/Layout/DefaultLayoutEngine.Target.cs
• doc/theming.md
• tests under tests/DiagramForge.Tests

Acceptance criteria

• repeated color selection rules are documented in code and in doc/theming.md
• generic nodes, snake, target, and XY chart follow the same documented precedence model unless a deliberate exception is documented
• themes with a 3-color NodePalette use that palette predictably rather than silently bypassing it
• themes created from FromPalette(...) continue to work, with the expanded derived palette participating in the same standard precedence rules
• targeted tests cover the agreed precedence behavior across at least generic nodes, snake, and XY chart

Why now

The Target Diagram work surfaced that DiagramForge has the right building blocks already, but color selection policy is still partially implicit and partially diagram-specific. Locking down the standard now will reduce future drift as more diagram kinds are added.

Start by reading src/DiagramForge/Models/Theme.cs and the candidate rendering and layout files, then inspect tests under tests/DiagramForge.Tests. Define the shared precedence rules before changing generic nodes, snake, target, and XY chart behavior. Done means the rules are documented in doc/theming.md and code, with focused tests covering the agreed behavior.