fix: resize Vega explore charts in place instead of re-embedding on every frame

[nishantmonu51]

Two independent problems made the Vega-rendered explore charts (any chart type with a dimension comparison, or a non-line chart type) misbehave when the divider between the charts and the leaderboards is dragged:

• Re-embed on every frame. svelte-vega stores the previous options in a Svelte $state proxy, so its === check on nested objects (config, tooltip, loader) never passes and its cheap view.width() path is never taken; every options change tore down and re-embedded the view. With YTD at day grain and several dimension values that was ~570ms per frame across three charts, which stalled the page and showed blank or stale clipped charts while dragging. VegaLiteRenderer now only includes the size in options when the options are (re)built, applies later size changes directly to the live view via view.width()/view.height() (vega-embed applies options.width the same way), and embeds only after the container is measured. A resize frame now takes ~70ms and keeps the existing canvases.
• Bars vanish at high density. Vega-Lite's bar.binSpacing defaults to a fixed 1px gap between time-unit bars on top of the proportional width: { band: 0.9 } gap. At day grain over 12 months a bucket is ~1.2px wide, leaving ~0.04px of bar, so the charts rendered as faint hairlines or looked empty, and appeared or disappeared with the width. The shared Vega theme now sets binSpacing: 0 so only the band gap remains and it scales with the bucket.

Verified on the dev project widened to ~50M rows across 12 months: explore stacked bars at 255px, 605px and 805px, canvas bar charts, and the chart export dialog.

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

https://claude.ai/code/session_01G27n7BGbcXjbE3mquSJfim

[AdityaHegde]

Claude's review,

• svelte-vega's own cheap path is genuinely unreachable. VegaEmbed.svelte stores prevOptions in $state (deeply proxied), so shallowEqual(options, prevOptions, WIDTH_HEIGHT) can never pass for nested keys like config/tooltip/loader. Its internal view.width() branch never runs. The PR is right to stop relying on it.
• The intent works. Generated code shows $.legacy_pre_effect(() => ($.get(baseOptions), $.get(measured)), …) — width/height are not tracked, because they're read inside withEmbedSize. A resize no longer changes options identity, so no re-embed during a drag.
• viewVL is tracked in the new resize effect ($.deep_read_state(viewVL())), so it correctly re-fires after each new embed.
• view.width() post-embed does stick. The specs use width: "container", which compiles to an initonly signal, and vega-dataflow's marshall() nulls _update after the first evaluation. vega-embed applies opts.width/opts.height the same way (embed.js:2836-2841), so the approach matches what the initial embed does.

The cost is, options now carries whatever size was current when baseOptions/measured last changed, so a re-embed caused by a spec change after a resize embeds at the stale size and then snaps — a visible flash plus a wasted layout pass. Previously the re-embed always used the current size. Reading width/height untracked at embed time (e.g. via untrack, or reading the live values inside the createView path rather than baking them into the memo) would keep the drag win without the regression.

[nishantmonu51]

@AdityaHegde : Handled review comment.