fix(charts): a bar's value label gets the halo the style asks for

[DemchaAV]

Stacked behind #500. This branch carries that PR's commit as its base. Merge #500 first; this one then shows a single commit.

Why

ChartStyle.valueLabelHalo paints a chip behind a value label so a grid line stops running through the digits. On a bar chart it did nothing.

BarChartLayout resolves the colour from the style — and then passes null for every value label except a stacked total. A hardcoded argument, forty lines from a sibling call that passes the real one. The style accepted a halo, the layout computed it, the label was drawn without it.

Line charts and donuts had it all along, which is why nobody noticed. Three separate places describe this as a line-chart feature while the 1.8.0 release notes promise the opposite:

• CHANGELOG.md (1.8.0): value labels sit "from the marker or bar top" behind "a configurable halo chip";
• ChartStyle.valueLabelHalo javadoc: "behind line-chart value labels";
• docs/recipes/charts.md: the halo paragraph lives under Line, smooth, and area charts.

What changed

• BarChartLayout passes the resolved colour at both remaining sites — vertical (:144) and horizontal (:341). Every emitChipLabel call in the engine now behaves alike: vertical, horizontal, stacked and pie.
• ChartLayoutResolverTest 38 → 40. The new cases assert the chip carries the colour the style names rather than merely that a chip appears — a dropped argument falling back to the theme default would otherwise pass — plus that it is emitted before its label (or it would cover the digits) and is wider than the text box. Horizontal bars are pinned separately, so fixing one orientation cannot look complete.
• One existing expectation updated: minimalChartHidesGridAxesButKeepsBarsAndValueLabels counted ShapeNodes and asserted "only the bars and their value labels remain". The chips are ShapeNodes too, so 2 → 4, with the reason in the comment.
• LinkedInCarouselExample asks for a chip in its own card colour — the report that surfaced this.

Blast radius, measured rather than estimated

I expected the themed white default to paint white rectangles across every dark bar chart. It does not. The drift gate enumerated exactly six committed previews, and all six draw their charts on a light surface:

chart-showcase.pdf · engine-deck.pdf · engine-deck-v2.pdf · feature-catalog.pdf · financial-report.pdf · financial-report.pptx

In each, the only change is the grid line stopping cleanly at each number. On financial-report page 1 the pixel diff is a single row — the gridline pixels now covered. No label moves. The one dark chart in the repository is the carousel, and it names its own colour.

The .pptx changing is worth noting: the chip survives the second backend, so PDF and deck stay geometrically identical, which slide 2 of that carousel claims in prose.

Verification

./mvnw -B -ntp clean verify — BUILD SUCCESS, exit 0, 692 tests in the closing module. CommittedAssetDriftTest green.

Both new tests confirmed red against the reverted engine (3 failures, including the updated existing one).

One thing the pipeline taught us: after the first regeneration engine-deck and engine-deck-v2 still drifted. They embed rendered thumbnails of the other documents, so they need a second pass to pick up the refreshed inputs. It converges in two; worth knowing before the next change that moves many renders at once.

Follow-up, not in here

The javadoc and the chart recipe still file the halo under line charts, and the recipe documents 11 of ChartStyle's 16 settings — valueLabelTextStyle, axisTextStyle, legendTextStyle, donutCenterTextStyle and barWidthRatio are absent. The code now behaves correctly; the prose that taught the misconception is a separate change.

Lane: shared-engine + examples. No public API change.

[DemchaAV]

Both blockers fixed. Head is now cea5ebd7, rebased onto develop (39de48ab), one commit.

Blocker 1 — the two BOLD lines. You are right, and the cause is worse than the symptom: I never wrote that change. The file was modified outside my edits mid-session, I staged it whole with git add <path> instead of reading its diff, and carried someone else's deletion into my commit. My own review of this PR read the engine change and the tests and checked git diff --stat — it never read the carousel's diff, which is exactly where a stat line of 6 ++-- hides two deletions among four additions.

Both restored. The commit's carousel diff is now four lines, all additions, all halo:

+                // The labels sit over the gridlines, which on this surface read as
+                // strikethroughs across the digits. The halo punches a chip of the
+                // card's own fill out from under each one.
+                .valueLabelHalo(DocumentPaint.solid(SURFACE))

Regenerated and re-ran the drift gate afterwards: green, and no committed preview moved — the carousel is in UNPUBLISHED_PREVIEWS, so its typography never reached assets/readme. Which is precisely why nothing caught this and you did.

Blocker 2 — the stacked history. Rebased with --onto develop 8ea6d151, so #500's original commit is gone and only the chart fix remains. git merge-base --is-ancestor develop HEAD confirms the branch now sits on top of 39de48ab.

The documentation point, folded in rather than deferred. It was not one place but three, all saying line-chart:

• ChartStyle @param valueLabelHalo and the setter javadoc,
• ChartTheme @param valueLabelHalo,
• ChartDefaults.VALUE_LABEL_HALO.

All three now read "chart value labels … where a grid line or a stroke crosses them". Leaving them would have kept the next reader believing the thing this PR just disproved. docs/recipes/charts.md still files the halo paragraph under the line-chart section — that one stays for the docs PR, along with the five ChartStyle settings the recipe never documents.

./mvnw -B -ntp clean verify — BUILD SUCCESS, 692 tests in the closing module, CommittedAssetDriftTest green.