feat(ci): pre-scan windows binaries before EV signing

[setohe0909]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes #issue_number

Screenshots

Type of change

Please delete options that are not relevant.

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ⚡ New feature (non-breaking change which adds functionality)
• 🚨 Hotfix (non-breaking change which fixes an issue)
• 📢 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📄 This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have checked my code and corrected any misspellings

[entelligence-ai-pr-reviews]

EntelligenceAI PR Summary

This PR introduces malware scanning steps into the Windows installer build workflow, executing scans before code signing using SSL.com's esigner action.

• Added unconditional malware scan step targeting the installer artifact
• Added conditional malware scan step for the app executable (runs only if file is present)
• Added conditional malware scan step for the uninstaller (runs only if file is present)
• All scan steps use scan_code command via sslcom/esigner-codesign@develop action with credentials from repository secrets

---

Confidence Score: 4/5 - Mostly Safe

Safe to merge — this PR introduces pre-signing malware scan steps into the Windows installer build workflow using sslcom/esigner-codesign@develop with scan_code commands, which is a meaningful security improvement to the CI pipeline. The conditional logic for scanning the app executable and uninstaller (guarded by file presence checks) is a reasonable defensive pattern. No issues were identified by automated review, and the change is additive and low-risk in nature. One minor concern worth noting is the use of the @develop floating ref for the sslcom/esigner-codesign action, which could introduce instability if upstream changes are made to that branch.

Key Findings:

• The sslcom/esigner-codesign@develop action uses a floating develop branch reference rather than a pinned commit SHA or stable tag, which means upstream changes to that action could silently alter behavior in future runs — pinning to a specific SHA would be more secure and reproducible.
• The conditional scan steps for the app executable and uninstaller correctly gate execution on file presence, which prevents spurious failures in configurations where those files may not be produced.
• The malware scan is appropriately placed before EV code signing, ensuring that artifacts are vetted prior to receiving a trusted signature — this is the correct ordering for a security-conscious pipeline.
• No logic bugs, missing validations, or security vulnerabilities were identified in the review; the PR is additive and does not modify existing signing or build logic.

Files requiring special attention

• .github/workflows/windows-installer-build.yml