Flaky gravity-charts visual tests: screenshot captured before async chart render

[korvin89]

Problem

The gravity-charts visual regression tests are flaky in CI (toMatchScreenshot mismatch) — they pass on fast machines / some CI runs and fail on others:

• src/plugins/gravity-charts/__tests__/Base.visual.test.tsx → "should render chart with valid data"
• src/plugins/gravity-charts/__tests__/SplitTooltip.visual.test.tsx → "should render tooltip in album orientation" / "should render tooltip in portrait orientation"

Root cause (test timing)

The tests call await render(<ChartTestStory .../>) and immediately toMatchScreenshot(), but @gravity-ui/charts renders asynchronously. On slower/loaded CI runners the screenshot captures a blank/partial canvas.

Evidence:

• First broke on the @gravity-ui/charts 1.55.2 → 1.56.0 bump (feat(deps): Update @gravity-ui/charts 1.55.2 -> 1.56.0 #892): https://github.com/gravity-ui/chartkit/actions/runs/27338492635/job/80768842932
• A /update-screenshots run once committed a 1001-byte (blank) Base baseline.
• The same baseline passed on chore(main): release 7.60.0 #893 but failed on feat(deps): Update @gravity-ui/charts 1.55.2 -> 1.56.0 #892 and on fix(highcharts): keep tooltip formatter override stable across re-renders #894 — classic flake.
• Committed linux baselines were last regenerated at feat(gravity-charts): improve split tooltip UX #815 (before the 1.56.0 bump), so they may also be pixel-stale.

Related product bug (reflow in withSplitPane)

While regenerating baselines, a real regression surfaced: in the HORIZONTAL split (portrait) the initial hover highlight on the split tooltip is lost. withSplitPane seeds data.defaultState.hoveredPosition to show an initial tooltip, but gravity-charts applies defaultState only once per mount. When the tooltip appears, the chart-pane resize calls chartRef.reflow({immediate: true}), which re-renders the chart and drops that one-shot highlight — desyncing the chart from the still-shown tooltip. (VERTICAL/album split has no such reflow, so it keeps the highlight.)

Existing attempt & decision

PR #895 attempts a fix (wait for render in tests + remount the chart via a key bump to re-apply defaultState). It is on hold — we decided the proper fix should address the reflow itself (so a reflow preserves / re-applies the hover highlight at the new pane size), rather than working around it with a chart remount.

Temporary mitigation

These tests are skipped in #894 via test.skip(...) referencing this issue, so unrelated PRs aren't blocked by the flake.

Fix direction

1. Tests: wait for the widget's render-complete signal (GravityChartsWidget exposes onReady → onRender/onLoad via afterFrame) before toMatchScreenshot.
2. Product: fix reflow in withSplitPane so the initial hover highlight survives the pane resize (don't rely on a remount).
3. Regenerate the linux baselines under charts 1.56.0 once the above are in.