fix(html): emit lengths the core parser can read

[LeadcodeDev]

Severity Medium, category coherence. Location: crates/rustmotion-html/src/style.rs:46

Impact

Two parsers for the same syntax have drifted. Executed: style="padding: 24px 48px; margin: 0 auto; grid-template-columns: repeat(3, 1fr)" transpiles to "padding":"24px 48px", "margin":"0 auto", "grid-template-columns":["repeat(3,","1fr)"]. All three deserialize successfully — Edges::Uniform(LengthPercentage::String) and GridTrack::Length(LengthPercentage::String) are untagged string variants — and then core's parse_length (rustmotion-core/src/css/units.rs:125) only understands a single number+unit token, so parse_length_or_warn (units.rs:262) falls back to Px(0.0): zero padding, zero margin, two zero-width grid tracks. The only signal is an eprintln! warning; validate exits 0 and the render is wrong. Per-side padding is entirely unexpressible from HTML (padding-top:32 is rejected by CssStyle's deny_unknown_fields, padding:32px 48px silently becomes 0), and the skill rule html-css-mental-model.md:97 only documents the JSON object form, which inline style="" cannot produce.

Fix

Teach parse_inline_style the standard 1/2/3/4-value box shorthands for padding/margin/border-radius, emitting the Edges/BorderRadius object the core expects, and teach the grid branch repeat()/minmax(); for anything still multi-token, return a named HtmlError rather than an opaque string. Long term, expose the core's parse_length from rustmotion-core and call it here so one grammar governs both front-ends.

Evidence the audit read

if prop == "grid-template-columns" || prop == "grid-template-rows" {
            let arr: Vec<Value> = value
                .split_whitespace()
                .map(|t| Value::from(t.to_string()))
                .collect();
            map.insert(prop, Value::Array(arr));
        } else {
            map.insert(prop, coerce_value(value));   // multi-token value -> opaque String
        }

Stacked on fix/html-unknown-attributes, which carries the previous finding of this workstream. GitHub shows only this finding's diff; merge in order.

Part of the September 2026 audit remediation chantier. Refs #220 (RM-04).