ci: pin the chocolatey toolchain and retry it

[zcsizmadia]

Closes #67.

Every GitHub action in these workflows is SHA-pinned, but the WinFsp SDK and the Inno Setup compiler were pulled at whatever version was current. That is the one unpinned input that reaches a release artifact: wsldrive.exe links against the downloaded winfsp-x64.lib, and wsldrive-setup.exe is produced by the downloaded compiler. A hijacked or simply broken package would ship.

choco is also the least reliable step in both workflows — a network blip failed the whole run, with no retry.

Both now go through scripts/ci/choco-install.ps1, which:

• holds the pins in one table — winfsp 2.1.25156, innosetup 6.7.1, the versions the last green run actually installed — so there is a single place to bump;
• retries three times with a widening backoff;
• keeps the existing treatment of exit 3010 ("installed, reboot pending") as success;
• refuses a package with no pin rather than quietly falling back to latest, so adding a tool means choosing a version.

Verification

• Script parses; resolves both pins; refuses an unpinned package with no pinned version for 'not-a-real-pin'.
• Both workflow files still parse as YAML.
• The install path itself is exercised by this PR's own CI run — if the pins were wrong, these checks would not go green.

Not done here: --checksum and artifact attestations, both mentioned on the issue. Checksums would need the per-version hashes maintained alongside the pins, and attestation is a release-workflow change worth doing on its own.