v0.13.3-pl.1

Step 3 follow-up — fixes three SVG-sizing regressions reported after v0.13.3.

All three symptoms had one root cause: the chart SVG sat in normal flow with width/height: 100% against a wrapper that only had min-height. Percentage heights do not resolve against a min-height-only parent, so the SVG fell back on its viewBox-derived intrinsic ratio (300×150 by default, or whatever the previous render's viewBox carried) and dragged the wrapper into that shape via the replaced-element sizing rules.

Symptoms now fixed

1. After picking Original again in the Aspect Ratio dropdown, the editor wrapper kept its previous aspect-ratio. The frontend was correct because PHP's Dimensions_Defaults strips the 'auto' keyword before render; the editor symptom was the SVG's stale viewBox holding the previous shape.
2. A freshly inserted block rendered at the SVG's 300×150 default (≈ 18.5vh on a typical viewport) instead of the documented 15vh baseline.
3. Enlarging min-height in the inspector grew the wrapper but left the chart frozen at the initial render size.

The fix

Absolute-position the chart SVG with inset: 0 (plus an explicit width/height: 100% for SVG-as-replaced-element correctness). The SVG now fills the wrapper's rendered content box without contributing to its intrinsic size, so the wrapper's height is determined purely by its own min-height / aspect-ratio / user-set values — exactly as the Step 3 design intended.

A new src/blocks/elevation/style.test.ts reads the SCSS file directly and pins the four CSS contracts (position: relative on the wrapper, position: absolute + inset: 0 on the SVG, and the min-height: 15vh baseline) so the rule cannot regress silently.

Acceptance

All five gates green: npm run build, composer test (480 / 1565), PHPStan, npm run test:js (345 / 29 suites), wp-scripts lint-js src/blocks/.