fix(batch): index the name template by character

[LeadcodeDev]

Severity Low, category correctness. Location: crates/rustmotion/src/cli/commands/batch.rs:74

Impact

resolve_name_template walks the template as raw bytes and casts each one to char, which in Rust is a Latin-1 reinterpretation of the byte value. Substituted {field} values are fine (they go through push_str at line 71); the literal text around them is not. I confirmed the behaviour by compiling the same loop standalone: résumé-{id}.mp4 yields résumé-VAL.mp4 and 动画-{id}.mp4 yields å¨ç»-VAL.mp4. So rustmotion batch --name-template "résumé-{id}.mp4" writes files literally named résumé-abc.mp4 to disk, and the same corruption lands in the [ok] <path> progress lines and in every failure message (item N: ...). A localisation batch — the exact use case {lang}/{id}.mp4 in the module doc is built for — is where a non-ASCII template is most likely. None of the five tests in name_template_tests (lines 448-495) uses a non-ASCII template.

Fix

Iterate template.char_indices() instead of the byte array, pushing the char itself and advancing by c.len_utf8(); the {/} scanning already works on byte offsets that are guaranteed char boundaries, so only the else-arm changes. Add a test asserting resolve_name_template("résumé-{id}.mp4", ...) round-trips the accents.

Evidence the audit read

} else {
            out.push(bytes[cursor] as char);
            cursor += 1;
        }

Stacked on fix/watch-cache-invalidation, 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-30).