fix(validate): keep asset paths relative when rewriting a scenario

[LeadcodeDev]

Severity Medium, category correctness. Location: crates/rustmotion/src/cli/commands/validate.rs:146

Impact

loaded.raw is captured AFTER rustmotion::assets::rebase_relative_paths(&mut json_value, dir) runs (crates/rustmotion/src/cli/commands/validation.rs:194-196), which rewrites every src/track string that names an existing file next to the scenario into a canonicalized ABSOLUTE path (crates/rustmotion/src/assets.rs:62-78). refuse_fix (validate.rs:81-109) only guards HTML, config/$, include, and for-each/use — nothing stops this. So rustmotion validate --fix scene.json on a scenario containing "src": "assets/logo.png" silently overwrites the source with "src": "/Users/alice/proj/assets/logo.png", which no longer resolves on any other machine or in CI, and pollutes the diff with paths the author never typed. This is the same class of unfaithful write-back that FixRefusal exists to prevent. Secondary hazard from the same line: rustmotion-studio enables serde_json's preserve_order (crates/rustmotion-studio/Cargo.toml:21) while crates/rustmotion/Cargo.toml:29 does not, so under resolver-2 feature unification a workspace build preserves key order but a standalone cargo install rustmotion build alphabetises every object in the rewritten file.

Fix

Keep an un-rebased copy of the post-expansion JSON in LoadedScenario (e.g. raw_unrebased) and serialise that in --fix; or re-read the file from disk, apply apply_fixes to those bytes, and write that back. Either way, also pin serde_json with features = ["preserve_order"] in the rustmotion crate so --fix never reorders keys.

Evidence the audit read

let mut json_value = loaded.raw.clone();
applied_fixes = apply_fixes(&mut json_value, &report_out.geom_violations);
if applied_fixes > 0 {
    let pretty = serde_json::to_string_pretty(&json_value)
        .map_err(|e| RustmotionError::Generic(format!("serialize fixes: {}", e)))?;
    std::fs::write(input, pretty)

Stacked on fix/geometry-transform-lengths, 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-16).