CT-11833 Build the Cyber Triage BitsParser.exe in CI

[jayaramcs]

Builds BitsParser.exe in CI the way #1's README describes the hand build, so Cyber Triage can download a pinned release instead of committing the exe (CT-11833, cybertriage/CyberTriage#3916). This follows the same ct_release pattern as cybertriage/libmsiecf and cybertriage/libesedb.

Fix

• CI build. A ct_release workflow builds the PyInstaller one-file BitsParser.exe for Windows x64 on Python 3.11.9. The packages are pinned in requirements.txt and requirements-build.txt.
• Release. Every run keeps the archive as a workflow artifact. Pushing a ct-* tag also publishes it, with SHA256SUMS, as a release.
• Docs. ct/README.md covers what differs from upstream, getting the exe, and releasing.

Details

Build

The workflow uses the same Python, packages and PyInstaller command as the build steps in Matt's README in #3916. The only difference is the output folder.

Smoke test

ct/smoke_test.py needs no BITS database. It checks that:

• BitsParser.exe -h runs, so every module is bundled, and offers --no-sid-lookup;
• a zero-filled file, run with the arguments BitsParserCommand passes, gives {"jobs": []};
• the exe bundles python311.dll, vcruntime140.dll and ucrtbase.dll (via pyi-archive_viewer -l -r), so it needs nothing installed.

Why no qmgr.db in this repository

• The 24H2 and Server 2025 fixtures are QA lab files, and this repository is public. So the real-data check stays in Cyber Triage's BITSDbParserTest, which runs on those fixtures.
• The README says to run that test before pinning a new release.

Release names

BitsParser has no version, so tags are ct-<yyyymmdd>.<n>.

Testing

• Smoke test on the current exe: passes on #3916's BitsParser_b153da3.exe.
• Current exe in an empty folder: parses the four fixtures (1, 1, 17 and 59 jobs), with no Owner field and no SID lookups.
• CI on this PR: this PR's own run is the first CI build. I'll compare its exe's output on the four fixtures with the current exe's before tagging.