fix(include): require opt-in for remote includes

[LeadcodeDev]

Severity Low, category security. Location: crates/rustmotion/src/include.rs:220

Impact

Any scenario handed to rustmotion render/validate can make the user's machine issue GETs to hosts of the author's choosing, with no host/scheme allowlist, no redirect policy, no timeout set on the call, and no --offline switch to refuse. On a developer laptop or a CI runner this reaches loopback services, RFC1918 addresses and cloud link-local metadata (169.254.169.254), and it doubles as a silent beacon that fires merely from validating a file (validation::load goes through the same resolve_includes). Fetching remote includes is clearly deliberate design, so the finding is the absence of any control around it, not the feature.

Fix

Gate remote includes behind an explicit opt-in flag (default deny), and when enabled reject non-public destinations after DNS resolution (loopback, link-local, RFC1918/ULA), set an explicit timeout, and cap the response size. Report the URLs a scenario wants to fetch before fetching them.

Evidence the audit read

fn fetch_remote(url: &str) -> Result<String> {
    let response = ureq::get(url)
        .call()
        .map_err(|e| RustmotionError::IncludeRemoteFetch {
            url: url.to_string(),
            reason: e.to_string(),
        })?;
---
    let is_remote =
        directive.include.starts_with("http://") || directive.include.starts_with("https://");

Stacked on fix/expand-node-budget, 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-46).