fix: make prop-derived chart values reactive (Area label position, Sparkline series type)

[rajanpanth]

Sibling fix to #3310 — same bug class, found by sweeping the other viz components for it.

Problem

Two chart components derive values from props with plain let declarations, freezing them at mount-time while their consumers are reactive:

• Area.svelte: let defaultLabelPosition = swapXY ? 'right' : 'top' — toggling swapXY after mount leaves the reactive labelPosition fallback stale (labels fall back to top on a swapped chart instead of right).
• _Sparkline.svelte: let seriesType = type === 'area' ? 'line' : type — seriesType is consumed inside the $: try config block, so mounting as bar and switching to line keeps rendering bars.

Fix

Derive both with $: so the reactive consumers see current values — the same one-line pattern as the stacked100 fix in #3310. Changeset included (patch, @evidence-dev/core-components).

Deliberately excluded from the sweep: the isInitial/queryID mount-time captures in core/* (intentionally non-reactive — they record initial state), and function-local lets.

Note on tests: #3310 establishes the regression-spec pattern for this class on BarChart; these two are the same one-line derivation change. Happy to add per-component specs if you want them — Area mounts inside chart context, so I kept this PR surgical.

[rajanpanth]

Pushed a follow-up commit: an untruncated re-sweep of the viz tree found the identical pattern in Line.svelte (defaultLabelPosition derived from swapXY with a plain let, consumed by the reactive labelPosition fallback) — now fixed the same way, and the changeset text updated. That completes the class: the only remaining prop-derived lets (_Chart's ySet/xSet) are intentionally non-reactive per their in-code comment and were left alone.

[rajanpanth]

Friendly follow-up on this PR 👋

When you have a moment, could you please take a look? I’m happy to rebase, update tests, or make any requested changes.

Thanks!

[rajanpanth]

The external-contributor test workflow is still waiting for maintainer approval. Could a maintainer approve the workflow run when convenient? The deploy previews and visible checks are otherwise complete.