fix: seed VSSCRIPT_PATH from Windows registry

[frankie1024]

Summary

On Windows, Av1an currently relies on one of these being true before VSScript can be loaded:

• VSSCRIPT_PATH is already set
• vapoursynth.exe is available on PATH

That misses a common installation state where VapourSynth is installed correctly, the VSScriptDLL registry value exists, but neither of the two discovery paths above is available to Av1an yet. In that case startup can fail with VSScript API not available.

This change adds a Windows-only fallback at process startup:

• if VSSCRIPT_PATH is missing or empty, read VSScriptDLL from HKCU\\SOFTWARE\\VapourSynth and HKLM\\SOFTWARE\\VapourSynth
• if the referenced DLL exists, seed VSSCRIPT_PATH before Av1an touches the VapourSynth bindings

Why here

The existing vapoursynth Rust crate already honors VSSCRIPT_PATH; the missing piece is that Av1an does not currently populate it from the standard Windows VapourSynth installation metadata.

Verification

Locally verified on Windows by:

1. Removing VSSCRIPT_PATH from the process environment
2. Removing the VapourSynth/Python entries from PATH
3. Running av1an --version

Before this patch, startup panicked with VSScript API not available.
After this patch, Av1an starts normally and detects VapourSynth through the registry-backed fallback.

I also ran cargo build -p av1an successfully.

Note: cargo test -p av1an still has pre-existing Windows vpy path escaping failures on master (for example encode_test_vpy_input), and this patch does not touch that area.

[FreezyLemon]

Looks sensible, but I wonder if this shouldn't be done in the vapoursynth crate...

[frankie1024]

Thanks for the review.

This PR is mainly to address the Windows case where VapourSynth is installed but VSSCRIPT_PATH is not set, which causes Av1an to fail finding VSScript.

The current change adds a fallback in Av1an so users can run without manually exporting the env var. I’ll add a short safety comment for the unsafe block.

Re the design question: I agree it may be cleaner for this to live in the vapoursynth crate long-term. I kept it in Av1an here as the smallest fix for the immediate user-facing issue, but I’m happy to move it upstream if that’s preferred.