Add tag-based, per-action releases (closes #1007)

[potiuk]

Consumers of this repo's actions could previously only track @main, which drifts from any pinned SHA and which Dependabot cannot bump (#1007). This adds path-prefixed, per-action releases.

Since it's a monorepo of actions, each action is tagged under its leaf-directory prefix with a moving major tag:

Action	Tag	Pin as
allowlist-check	allowlist-check/vX.Y.Z	.../allowlist-check@<sha> # allowlist-check/v1.2.3
pelican	pelican/vX.Y.Z	.../pelican@<sha> # pelican/v1.2.3
stash/save	save/vX.Y.Z	.../stash/save@<sha> # save/v1.2.3
stash/restore	restore/vX.Y.Z	.../stash/restore@<sha> # restore/v1.2.3

This leaf-prefix scheme is exactly what Dependabot's github_actions ecosystem learned to support in dependabot/dependabot-core#11286, contributed for this repo, so downstream projects pin a SHA with a # <prefix>/vX.Y.Z comment and receive automatic bump PRs.

How it works

• .github/workflows/release-actions.yml runs on push to main; scripts/release_actions.py maps changed files to the affected action(s), computes the next version from the newest <prefix>/vX.Y.Z tag (first release seeds v1.0.0), creates the tag, moves the major tag, and publishes a GitHub Release.
• Bump defaults to patch; raise with a release:minor / release:major label (or [minor]/[major] in the PR) and suppress with release:skip. A stash/shared/ change releases both stash actions.
• workflow_dispatch cuts a manual/seed release.
• Pure logic is unit-tested (scripts/test_release_actions.py, 25 tests); see RELEASING.md.

Merging this PR cuts no release (it touches no action directory); the first tags come from the next action change or a manual workflow_dispatch seed.

🤖 Generated with Claude Code

[potiuk]

Hey: @dfoulks1 @ppkarwasz @dave2wave @gopidesupavan -> proposed solution to the issue we had whether to host actions in separate repos - because of dependabot release handling.

Since Pavan implemented feature in dependabot o handle prefixed version - it's now entirely doable to do the prefix/vX.Y.Z

The solution proposed in this PR is largely self-maintainable:

1. We merge
2. We manually run "worfflow-dispatch" to released first version of actions (say 1.0.0 for all - they are all well tested)
3. any future change to an action will automatically bump patchlevel - so all we need to do to relase new version is to push a fix.
4. we can also add release:minor, release:major in a PR to bump Y or X instead

I think it's pretty good solution for zizmor/dependabot combo.