Harden GitHub Actions workflows and add a zizmor security gate

[mostafa]

Summary

• Hardens every GitHub Actions workflow: pins each uses: by full commit SHA with a version comment, sets least-privilege permissions (top-level plus per-job overrides), adds concurrency groups, keeps checkouts credential-free, and passes matrix values into run: steps through env vars to avoid template injection. A Dependabot cooldown is also added. These are hardening-only changes with no behavior change to the build, test, or release jobs.
• Adds a zizmor workflow-security gate (pedantic persona) that audits the workflows on pull requests and pushes touching .github/workflows/**, plus a .github/zizmor.yml config. All workflows pass zizmor --persona=pedantic locally, with one justified ignore (the release job keeps softprops/action-gh-release for its multi-asset upload and generated notes).

Test plan

• zizmor --persona=pedantic .github/workflows/ reports no findings
• The existing fmt, clippy, test, and build jobs run unchanged on this PR

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[Karib0u]

Thanks for the hardening pass. I spotted two workflow issues worth fixing before merge:

1. In .github/workflows/ci-cd.yml, the bpf-linker cache uses lookup-only: true, but the install step is skipped when cache-hit == true. On a fresh runner with an exact cache hit, the cache action will not restore ~/.cargo/bin/bpf-linker, yet cargo install bpf-linker will be skipped. Please remove lookup-only for that cache, or gate the install step on the actual binary existing.

2. In .github/workflows/zizmor.yml, the path filter only includes .github/workflows/**. Since this PR adds .github/zizmor.yml, future changes to the zizmor config alone would not run the zizmor workflow. Please add .github/zizmor.yml to both the push and pull_request path filters.

[mostafa]

Thanks, both fixed, and I rebased the branch onto the current main (which now includes #101).

• bpf-linker cache: option A (dropping lookup-only) would let the cache restore, but since this workflow also publishes release artifacts, the zizmor pedantic gate this PR adds flags any restoring cache as a cache-poisoning vector. So I went with your option B and made the install robust instead: the step no longer caches bpf-linker and installs it idempotently (command -v bpf-linker >/dev/null 2>&1 || cargo install bpf-linker). An exact cache hit can no longer skip both the restore and the install, the eBPF build always has the linker, and zizmor stays clean with no new ignores.
• zizmor path filter: added .github/zizmor.yml to both the push and pull_request paths so config-only changes trigger the audit.

Conflict: main advanced with the merged RSigma backend and some dependency bumps. I merged main in and resolved the ci-cd.yml conflict by keeping the hardened workflow (pinned actions, least-privilege permissions, concurrency, credential-free checkouts, env-passed matrix values) while carrying over main's --features rsigma-engine release builds. The branch is now even with main and the net diff is hardening-only. zizmor --persona=pedantic .github/workflows/ reports no findings.