fix invalid CI files

[Wikid82]

No description provided.

[Copilot]

Pull request overview

This PR adjusts several GitHub Actions workflows to fix invalid configurations around manual triggers and Docker image handling, particularly for E2E and integration test jobs.

Changes:

• Add a shared image_tag input to multiple workflow_dispatch triggers so the existing “Determine image tag” logic is valid and usable for manual runs.
• Simplify the E2E tests workflow’s concurrency key to a context that’s always available and remove direct registry pulls in favor of downloading the locally built Docker image artifact.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
.github/workflows/waf-integration.yml	Adds an image_tag input to workflow_dispatch so the WAF integration job’s MANUAL_TAG: ${{ inputs.image_tag }} reference is valid and can override the image tag on manual runs.
.github/workflows/rate-limit-integration.yml	Adds the same image_tag input for the rate-limit integration workflow, enabling manual image tag selection consistent with its existing tag-resolution logic.
.github/workflows/e2e-tests.yml	Extends workflow_dispatch with an image_tag input, simplifies concurrency.group to use github.ref, and switches the test job from pulling an image from GHCR to downloading the docker-image artifact (charon-e2e-image.tar) built in the build job.
.github/workflows/crowdsec-integration.yml	Adds an image_tag input to the CrowdSec integration workflow, aligning manual triggers with its tag-determination and registry/artifact retrieval logic.
.github/workflows/cerberus-integration.yml	Adds an image_tag input to the Cerberus integration workflow, making its manual override path for image tags valid and configurable.

[Copilot]

The new image_tag workflow_dispatch input is currently not wired into the E2E job’s image selection: the job always loads charon-e2e-image.tar from the build artifact and ignores the Determine image tag step outputs, so providing an image_tag when manually triggering this workflow has no effect. To avoid confusion and dead code, either connect this input/step to the image loading / docker-compose logic, or drop the input (and possibly the tag computation) if the workflow is intended to always use the locally built image.