Add graph lane tokens to the color scheme

[AhmadKharfan]

Why

GitGraphGutter builds a categorical palette — indexed palette[lane % size] purely to tell branch lanes apart. The colours carry no meaning; they only need to be distinguishable. It was assembled from three unrelated sources:

colors.accentPrimary                  // Asl token — CHANGES with the user's accent setting
MaterialTheme.colorScheme.tertiary    // Material 3 stock pink
MaterialTheme.colorScheme.secondary   // Material 3 stock lavender
colors.error                          // Asl token that MEANS "error"
Color(0xFF43A047)                     // hardcoded, identical in light and dark
Color(0xFFFF8F00)                     // hardcoded, identical in light and dark

Measured in CIE-Lab ΔE, three real defects:

Defect	ΔE
lane1 vs lane2 — the two Material stock colours are the least distinguishable pair	17.9
lane3 is the error colour — a branch rendered in the failure colour	0
lane0 follows the accent; with Amber it is the warning colour	0

Plus two hardcoded lanes that never adapt between light and dark, and Material pink/lavender belonging to no palette this app uses.

What changed

Added AslColorScheme.graphLanes: List<Color> — a genuinely new kind of token. Every other colour here is semantic (error, warning, success, accentPrimary); this one is categorical, which is why nothing existing fit and why substituting an existing token would have been wrong.

GitGraphGutter now reads colors.graphLanes. The lane indexing, Canvas geometry, stroke widths and gutter dimensions are untouched.

How the colours were chosen

Not by eye. An exhaustive search over hues already present in this app's design language, required to satisfy three constraints at once:

Constraint	Target	Dark	Light
Minimum pairwise ΔE within the palette	≥ 20	40.4	43.6
Minimum ΔE to error / success / warning / info	≥ 20	pass	pass
Minimum ΔE to all three accents (emerald, fjord, amber)	≥ 20	pass	pass

The second constraint means a lane can never read as a status colour. The third means no accent setting can make two lanes look alike — the current palette fails this, since lane 0 follows the accent.

Worst-case separation improves from 17.9 to 40.4.

Behavior

Branch lane colours change. This is deliberate and is the point of the change. Everything else about the graph renders identically.

Light and dark were verified as correctly assigned rather than swapped — a swap would compile cleanly and look wrong only at runtime.

Scope

This is the last MaterialTheme.colorScheme usage outside the design system. The only remaining one in the whole repo is Theme.kt:67, inside AslAppTheme itself — the adapter that installs the Asl tokens into Material3, and the one legitimate consumer.

The hardcoded literals 0xFF43A047 and 0xFFFF8F00 are gone; no other file duplicates them.

Tests

No new tests. A token addition with no logic; the palette's properties were verified analytically before implementation rather than asserted at runtime.

Verification

• ./gradlew test — all modules pass.
• ./gradlew :app:compileDebugKotlin — passes.
• ./gradlew detekt — passes.
• Both palettes diffed against the verified search output, hex by hex.
• Confirmed light values are in AslLightColors and dark in AslDarkColors.
• Confirmed the three palette[...] index sites are unchanged apart from their source.

Baseline

feature/git/detekt-baseline.xml regenerated — 1 removed, 0 added. Project total 241 → 240.

Correction to an earlier claim

A previous PR description asserted the Amber accent collided with lane 5 "at RGB distance 60". That used Euclidean RGB distance, which is a poor perceptual proxy. Measured properly, that pair is ΔE 28.2 and the Emerald/green pair is ΔE 27.7 — both distinguishable. The genuinely confusable pair was tertiary vs secondary at ΔE 17.9, which is what this change fixes.