Floating tag `v1` still points to `v1.0.0` (Node 16) — please move it to the latest v1.x release

## Issue

The floating major tag `v1` currently points to the same commit as `v1.0.0` (`6878686fce27aeb6f49009173b2947a400e282b5`, released Nov 2022), even though three patch releases have shipped since:

| Tag | Commit | `runs.using` |
|--------|------------|--------------|
| `v1` | `6878686f` | **`node16`** |
| `v1.0.0` | `6878686f` | `node16` |
| `v1.0.1` | `0181c1c9` | (node16/20) |
| `v1.0.2` | `a06d172c` | `node20` |
| `v1.0.3` | `2d89ee0b` | **`node24`** ✅ |

The [GitHub Actions recommended release management practice](https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions#using-release-management-for-actions) is to keep the major tag (`v1`) up to date with the latest patch release inside that line — so consumers that pin `@v1` automatically get bug fixes and runtime updates.

## Impact

Anyone pinning `uses: allure-framework/setup-allurectl@v1` today gets `v1.0.0` running on **Node.js 16**.

GitHub Actions runner now emits a deprecation warning for any Node 16/20 action and has announced removal dates ([changelog](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/)):

- **2026-06-16** — runner forces Node 24 by default
- **2026-09-16** — Node 20 removed from the runner (Node 16 already deprecated)

After 2026-09-16, all consumers pinning `@v1` will break unless they switch to `@v1.0.3` (or a future `@v2`) — which is awkward because they explicitly chose to track the floating major tag for upgrades they don't have to think about.

Dependabot also can't help here: it sees `@v1` as the latest major and doesn't propose `v1.0.3` updates because semantically the version a consumer pinned (`v1`) is still resolvable. We see this in practice across many repositories we maintain at https://github.com/dodobrands and https://github.com/dodopizza.

## Suggested fix

Re-create the `v1` tag on `2d89ee0b7ba2f59dbe9849b6df5763cab78e14db` (current `v1.0.3`):

```bash
git tag -f v1 v1.0.3
git push origin -f v1
```

Optionally automate this for future releases (e.g. via [`actions/publish-action`](https://github.com/actions/publish-action) or a small workflow that moves the major tag on every published release).

Happy to send a PR with such an automation workflow if it would help. Thanks!

Start by verifying the current v1, v1.0.3, and release tag targets described in the issue, then inspect any release or publishing workflow relevant to moving the major tag. Done means v1 resolves to the v1.0.3 commit and consumers using @v1 receive the current Node 24 action; future automation is optional as described.

Written by the indexing model from the issue text.