v0.13.5-pl.7

Reverts pl.3's typography inline-style hack and restores the pl.1 SCSS-only architecture.

The pl.3 commit added an inline style attribute on the chart's host <svg> because typography appeared not to reach the rendered tick labels in the Gutenberg editor. A diagnostic snippet run against the maintainer's actual live site (Ollie theme, ~30 plugins including wp-typography and fluent-crm which force the editor into non-iframe mode) and against a DDEV mirror proved the pl.3 diagnosis wrong: after stripping the inline style at runtime, getComputedStyle(svg) resolves to exactly the user's chosen typography (Mona Sans Condensed, 2rem, 800, italic → computed Mona Sans Condensed, sans-serif / 32px / 800 / italic) in both environments. The SCSS rule on .kntnt-gpx-blocks-elevation .kntnt-gpx-blocks-elevation-chart-svg is sufficient on its own. No theme rule overrides it.

What changes

• src/blocks/elevation/chart.tsx: removes the typographyToSvgStyle() helper and the style={ … } prop on <svg>; restores the pl.1 JSDoc on ChartProps.typography (prop retained as a useLayoutEffect dep-list trigger only).
• src/blocks/elevation/chart.test.tsx: drops the two pl.3 pinning tests; adds a pin against future reintroduction of inline typography on the SVG.
• docs/elevation-rebuild.md § Step 4 recap: appended paragraph recording the diagnosis and architectural choice.

What stays the same

• Frontend behaviour: unchanged. The SCSS path was already the only mechanism on the frontend.
• Server-side wrapper-custom-property emission (Render_Elevation::build_inline_style()): unchanged.
• Editor-side wrapper-custom-property emission (ElevationEdit's inlineStyle builder): unchanged.
• pl.2, pl.4, pl.5, pl.6: all untouched.