feat: GS-1 centre lines are double-yellow — row 7 closed (13/14)

[JArmandoAnaya]

The held half of #193, unblocked now that #195 is merged and #203 landed the authoring op. Closes GS-1 row 7 and retires gap 5a.

#193's premise was incomplete — row 7 was blocked by two gaps, not one

The issue said:

Kernel support for dual-geometry marks and roadMark colour landed in #69; what is missing is the authoring side.

Half true. #69 landed colour in the data model and the writer, and the dual-stripe geometry. It never landed a path from RoadMark::color to the mesh — SubMesh had no colour field, and scene_builder.cpp:117 painted every marking one hardcoded off-white.

I found this the only way it can be found: I rebuilt the scene, got color="yellow" in the .xodr and 0 diagnostics, and the render still came back white. GS-1's spec ticks rows against the committed baseline render — so on the data alone, row 7 was not closeable, and ticking it would have been a lie the baseline itself disproved.

The committed baseline in this PR is the proof: centre lines double-yellow down every arm, edge lines still white.

So this PR closes both halves.

1. Authoring — build_gs1.py calls junction_center_marks

GS-1: roads=16 junctions=1 objects=36 signals=6 diagnostics=0 errors=0
$ grep -c 'type="solid solid"' assets/samples/gs1_urban_intersection.xodr   → 4
$ grep -c 'color="yellow"'     assets/samples/gs1_urban_intersection.xodr   → 4

Reloaded from disk: 0 load diagnostics, 0 validator findings.

2. Render — the mesh carries the colour

SubMesh gains mark_color (the normative e_roadMarkColor, not RGB — the kernel stays render-free), the builder sets it from the mark, and the editor maps it to paint. Standard and White both resolve to the off-white markings have always used, so nothing that never asked for a colour changes appearance.

Score: 12 / 14 → 13 / 14

Gap	Was	Now
7 centre double-yellow	GAP → #193	closed — authored and rendered
5a left/right arrow glyphs	GAP → #193	closed by the per-lane chooser (#203)
8 dashed white lane lines	GAP → #194	still open — needs a wider profile, not marks

5a closed, but GS-1 still authors straight — deliberately

The chooser means a turn-lane scene can author arrowLeft/arrowRight. GS-1 doesn't, and shouldn't: one lane per direction serves left, straight and right at once, so no single turn glyph is correct. The normative answer is arrowStraightLeftRight (§13.14.8 Table 117), which doesn't mesh yet. The spec says this in place rather than leaving "straight only" looking like an oversight.

The baseline: refreshed in place, not forked

My plan said to fork a v0.7.0 baseline so v0.6.0's stayed frozen as published evidence. That premise was wrong:

$ git tag -l        → v0.1.0  v0.2.0  v0.3.0
$ gh release list   → v0.3.0 (Latest)
CHANGELOG           → [0.6.0] - Unreleased, [0.5.0] - Unreleased, [0.4.0] - Unreleased

v0.6.0 was never tagged. Merging #195 landed the close-out; it didn't publish it. So gs1_baseline_v0.6.0.png certifies nothing yet and no one holds a copy a refresh would invalidate. Forking a v0.7.0 row would have frozen a baseline for a release that doesn't exist and permanently recorded GS-1 as 12/14 at M3a when it's 13/14 before the tag cuts.

One baseline, refreshed in place — exactly what the golden-scenes README prescribes: "A render that changes for a legitimate reason … refreshes the baseline in the same PR, with a note saying why."

Also: #38 and #73 are still open. #195 said "Refs", not "Closes", so they never auto-closed — M3a isn't formally closed, which is what makes landing row 7 inside it legitimate rather than a retcon.

Baseline downloaded from this branch's own CI artifact (run 29412174160, head b5d1ea1) and looked at before committing. The README hero re-shot with it — same scene; a hero whose centre lines disagreed with the baseline beside it would be its own small lie.

Also in this PR

CHANGELOG.md [0.6.0]: the centre-mark/arrow feature and the render colour under Added; today's three fixes (#202 split_road colour/lines, #205 junction-menu reachability, #144 prop-drag clamp) under Fixed; GS-1 "Known gaps" narrowed to row 8 alone.

Checks

• ci-macos clean (-Werror); 747/747 ctest green; 14/14 CI.
• New tests: RoadMarks.MarkColorReachesTheSubMesh (colour reaches the mesh; an uncoloured mark stays Standard), MarkPaint.YellowIsDistinctFromTheWhiteDefault, BuildScene.MarkingItemsTakeTheirRoadMarkColor.

Refs #193, #73, #69