Added QC Preflight Checks workflow configuration

[njjetha]

Summary

Added workflow file to run automated Qualcomm preflight checks on every PR and push to main. This workflow enforces project quality and compliance standards by running:

Semgrep scan – static code analysis for security/bug patterns
Dependency review – flags vulnerable or license-incompatible dependencies
Repolinter check – validates repo structure against project standards
Copyright/license check – ensures all files have proper license headers
Commit email check – verifies commits are made with approved email addresses

These checks help maintain code quality, security, and open-source compliance across contributions.

[njjetha]

@R-Bower Can you please explain why you have move semgrep to cron job. We are moving away from Semgrep token because it has certain limitation as we are using Semgrep Community Edition
Contributor Limit: The free tier is limited to 10 monthly contributors.
Repo Limit: Free accounts can scan up to 50 repositories.

[mynameistechno]

Can you please explain why you have move semgrep to cron job.

Was this to speed up PRs? It still runs on pushes though. BTW there was an issue with how we were using Semgrep previously, this fixes some issues with PR comments not showing up.

Can you access this https://github.com/qualcomm/qualcomm-ui-utils/security/code-scanning ? Have you been getting alerts? Just curious.

One thing we still QPSI to provide guidance and guidelines on maintainer expectations regarding Security alerts and semgrep. There are many false positives and levels of severity etc.

[R-Bower]

Can you please explain why you have move semgrep to cron job.

Was this to speed up PRs? It still runs on pushes though. BTW there was an issue with how we were using Semgrep previously, this fixes some issues with PR comments not showing up.

Can you access this https://github.com/qualcomm/qualcomm-ui-utils/security/code-scanning ? Have you been getting alerts? Just curious.

Yes, I've been getting + addressing alerts over time.

One thing we still QPSI to provide guidance and guidelines on maintainer expectations regarding Security alerts and semgrep. There are many false positives and levels of severity etc.

I've noticed this. The issue is that most of our dependencies are dev-only, or only ever run locally on developer machines. Very rarely I'll see a vulnerability on a transitive dependency for one of our public packages that runs in the browser. The issue with semgrep is that it's very difficult for it to determine whether a given dependency runs on Node.js (i.e. offline/dev/server-only) or in the browser. I am still figuring out how to solve that problem.

[R-Bower]

@mynameistechno looks like this is significantly faster than it was before. LGTM. I'll run some tests on the main qualcomm-ui repository with these enabled.