fix: preserve BarChart axis and colors when switching to stacked100

[rajanpanth]

Description

Fix BarChart updates when the type prop changes dynamically between stacked and stacked100.

Previously, BarChart derived its stacked100 normalization flag only during component initialization. A later type update reached the bar series but left the core chart using the previous normalization mode. Entering stacked100 therefore retained raw values, while leaving it retained normalized fractions, producing incorrect axis semantics and an apparent series-color collapse even though the series identities and palette remained intact.

Changes

• derive stacked100 reactively from type
• add regression coverage for forward, reverse, repeated, and initial stacked100 rendering
• add a patch changeset for @evidence-dev/core-components

Testing

• pnpm --filter ./packages/ui/core-components test:unit --run src/lib/unsorted/viz/bar/BarChart.spec.js — 4 passed
• pnpm --filter ./packages/ui/core-components test:unit --run — 121 passed, 3 pre-existing skipped
• focused ESLint and Prettier checks for all changed files — passed
• pnpm --filter ./packages/ui/core-components build — passed, including svelte-package and publint
• pnpm changeset status --since=origin/main — passed
• git diff --check — passed

The package-wide Svelte check remains blocked by existing diagnostics in unchanged files. The aggregate lint command is also blocked by the current Prettier/YAML baseline; every changed file passes focused formatting and ESLint validation.

Before

Dynamic transitions could leave the chart data normalization and axis formatting in the previous stacked mode.

After

Normalized data, raw data, axis formatting, series identity, and distinct palette colors consistently match the active chart type across forward, reverse, and repeated transitions.

Screenshots

No screenshot is included. The existing Storybook environment fails before rendering BarChart stories with a pre-existing fromStorybook runtime error; the behavior is covered deterministically at the generated ECharts configuration boundary.

Related issue

Fixes #3299

Compatibility

No public API change. Initial rendering and unrelated chart types remain unchanged. The runtime addition is one reactive boolean comparison when type changes.