chore: Harden all GitHub Workflows using Zizmor

## Tool

`zizmor` —

## GitHub Action

`zizmor-action` —

## Goal

Harden all GitHub workflows using automated analysis and recommendations.

## Implementation idea

- Add `zizmor` as a dedicated GitHub Actions workflow that analyzes all workflows in `.github/workflows/**`.
- Run it:
- on every pull request (**only when** files under `.github/workflows/**` changed), and
- on a weekly schedule (scan the full `.github/workflows/**` set).
- Triage findings and apply recommended changes to workflows to improve security/compliance.

## Triggers (detailed)

- `pull_request`:
- `paths: [".github/workflows/**"]`
- Runs for PRs targeting the default branch (and/or the repo’s main development branches as applicable).
- `schedule`:
- weekly cron (e.g., `"0 0 * * 6" # Every Saturday 00:00 UTC`)
- Always scans all workflows under `.github/workflows/**` (not change-filtered).

## Behavior on findings

- If `zizmor` finds issues in a pull request run, the workflow check **must fail** (block merge) until findings are addressed.
- Reporting should use GitHub **annotations** if possible; otherwise fall back to clear text output in logs/job summary.

## Output / Reporting

- Preferred: GitHub annotations surfaced directly in the PR checks UI.
- Fallback: simple text output (logs and/or job summary) that clearly lists findings.

## Implementation details / constraints

- Workflow file: `.github/workflows/zizmor.yml`
- Runner: `ubuntu-latest`
- Permissions: least privilege (default to `contents: read`, add only what is required)
- Add reasonable `timeout-minutes` to avoid hanging runs.

## Acceptance Criteria

- A `zizmor` workflow exists in `.github/workflows/` and runs on:
- `pull_request` events with `paths: [".github/workflows/**"]`, and
- a weekly `schedule`.
- PR runs are **blocking**: the check fails if findings are detected.
- Findings are surfaced via annotations where possible; otherwise via simple text output.

## Exit Criteria

- All `zizmor` findings are addressed by either:
- fixing them in the same pull request that introduced them, **or**
- creating individual follow-up ticket(s)/issue(s) to track and complete the remediation.

Start by inspecting the existing files under .github/workflows/** and the zizmor and zizmor-action documentation. Add .github/workflows/zizmor.yml with the specified pull_request path filter, weekly schedule, least-privilege permissions, and timeout. Done means findings are reported and PR checks fail when zizmor detects issues, while the scheduled run scans all workflows.

Written by the indexing model from the issue text.