fix(validate): stop render blocking on unresolved variables validate allows

[LeadcodeDev]

Closes #187.

What

$ rustmotion validate -f var.json
Valid scenario: 1 scene(s) in 1 view(s)                              exit 0

$ rustmotion render -f var.json -o var.mp4
Error: Validation failed: 0 schema error(s), 0 geometry violation(s),
       1 unresolved variable(s).
       Run `rustmotion validate -f <file>` to see details.           exit 1

The refusal told the user to run validate, which reports the file as valid. There was no command that showed the problem.

Which side was wrong

Not the one I expected. validate was following the documented decision — variables.rs (constat #7) settled that a leftover $word cannot be told apart from legitimate literal $ content (a price tag, a terminal $PATH, a shell $HOME), so it is reported as a loud warning rather than aborting; a hard rejection would break any existing scenario with a $ in its text, and would do so only once the file happened to gain a config block.

ValidationReport::is_blocking never got that memo, and render goes through it.

So the fix is to remove the unresolved_vars term from is_blocking, not to add it to validate.

Behaviour change

A typo'd $variable now renders as literal text instead of stopping the render. That is the intended trade-off, and nothing that reaches this point is a diagnosable typo: every declared variable is present in defaults ∪ overrides, so substitute cannot leave one behind, and a for-each/use mistake is already named and located by expand.rs.

unresolved_vars stays in is_clean, so both commands still print the warning — what changed is what happens next, not whether it is reported.

After

$ rustmotion validate -f var.json   → exit 0, warning printed
$ rustmotion render  -f var.json    → exit 0, warning printed, var.mp4 written

Test

an_unresolved_variable_warns_without_blocking uses "$9.99 a month" — the exact content the design decision is about — and asserts all three properties: it is reported, it does not block, and is_clean stays false so it cannot be silently dropped.

cargo test --workspace green, cargo fmt --check and cargo clippy --all-targets -- -D warnings clean.