…es (erigontech#21100)

## Context

The `update-disk-sizes.yml` workflow uses a `workflow_run` trigger.
GitHub evaluates `workflow_run` events against the workflow file on the
**default branch** (`main`). Without this file on `main`, successful
sync runs on `release/3.*` would not invoke the collector workflow added
by erigontech#21030.

This PR adds the file to `main` so the trigger fires, then iterates on
hardening to keep this copy aligned with the release-branch copy.

## What this PR does

Adds `.github/workflows/update-disk-sizes.yml` to `main`. Behavior is
functionally identical to erigontech#21030's copy on `release/3.4`; the
differences below are pure hardening / lint cleanup, mostly driven by
Copilot review and a zizmor security pass.

### Trigger scope

- `workflow_run` listens for `release/3.*` runs of the QA sync
workflows, **plus** `main` for the scheduled QA runs (so they also feed
the collector).
- The release-branch copy intentionally stays narrower (`release/3.*`
only). The single-line difference between the two files after both land.

### Input safety

- **`workflow_dispatch` inputs validated** before any value is
propagated downstream: numeric `run_id`, allowed-char `base_branch`,
`full|minimal` `prune_mode`. Anything else exits non-zero.
- **`GITHUB_OUTPUT`** used instead of `GITHUB_ENV` for `prune_mode` /
`source_run_id` / `base_branch` propagation. Step outputs are not
environment variables, so zizmor's `github-env` rule doesn't fire on
potential code execution paths.
- **Per-step `env:` blocks** instead of template substitution into shell
scripts — no template-injection findings.

### Robustness

- **"Verify artifacts are present"** step that fails fast if the
download yielded an empty directory (instead of silently producing an
empty JSON update).
- **`persist-credentials: true`** explicit on the checkout (the later
`git push` needs them).
- **Quoted branch variables** throughout the push / PR-lookup paths.
- **`set -euo pipefail`** on multi-line shell blocks.
- **Normal `git push`** instead of `git push --force` for the
auto-update branch.

### Tooling and review

- **Action bumps**: `actions/download-artifact@v7 → @v8`,
`actions/setup-python@v5 → @v6`, aligning with the rest of the repo.
- **`# zizmor: ignore[dangerous-triggers]`** on the `workflow_run`
trigger with justification — this workflow never checks out the
triggering run's head, and `BASE_BRANCH` is pinned per-event (not
derived from untrusted input).
- Addressed all Copilot review threads across the iteration cycle
(`690c6927` — `download-artifact@v8`, env-based handling for
`workflow_dispatch` inputs, `workflow_run.branches` includes `main`).

## Test plan

- [x] CI passes on this PR
- [x] No functional change vs. the existing `release/3.4` copy beyond
the `branches:` filter widening
- [ ] After this and erigontech#21271 both merge: diff the two files — single-line
difference on `branches:` only

Related: erigontech#21030, erigontech#21271

---------

Co-authored-by: Gianni Morselli <gianni.morselli@erigon.tech>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Bloxster <bloxster@proton.me>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…21278)

## Summary

Addresses [lystopad's review
comment](erigontech#21100 (comment))
on erigontech#21100, which merged before it could be addressed.

The `Configure git` step in `update-disk-sizes.yml` was using the
generic `github-actions[bot]` author. Lystopad's feedback:

> Please, use another name here which would clearly points to this
workflow. For example something like:
> ```
> git config user.name "github-workflow-update-disk-sizes-run-${RUN_ID}"
> ```
> Otherwise it would be hard to understand source of the change in
target repo.

## What changed

`.github/workflows/update-disk-sizes.yml` — `Configure git` step:

```diff
       - name: Configure git
         if: steps.diff.outputs.changed == 'true'
+        env:
+          RUN_ID: ${{ github.run_id }}
         run: |
           set -euo pipefail
-          git config user.name "github-actions[bot]"
+          git config user.name "github-workflow-update-disk-sizes-run-${RUN_ID}"
           git config user.email "github-actions[bot]@users.noreply.github.com"
```

- **Name change**: `github-actions[bot]` →
`github-workflow-update-disk-sizes-run-<run-id>`. The auto-update commit
now names the specific workflow and the exact run, so anyone
investigating the commit in the target repo can jump straight to the run
that produced it.
- **`RUN_ID` propagated via `env:` block**, consistent with the rest of
the workflow's anti-template-injection pattern (no template substitution
into shell).
- **`user.email` unchanged** —
`github-actions[bot]@users.noreply.github.com` still keeps the commit
attributed to the bot. Lystopad's suggestion only addressed `user.name`.

## Test plan

- [x] YAML syntax check (`yamllint`-style by visual inspection — single
`env:` insertion)
- [ ] First `update-disk-sizes` workflow run after merge: confirm the
produced `chore(docs): auto-update measured disk sizes` commit has
author `github-workflow-update-disk-sizes-run-<id>` (where `<id>`
matches the workflow run ID linked from the commit annotation)

Related: erigontech#21100, erigontech#21271

Co-authored-by: Bloxster <bloxster@proton.me>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>