chore(ci): automate weekly release via pipeline schedule

What

Automates the weekly CLI release so a new version is cut every Sunday without manual tagging.

A scheduled pipeline can't be the release, because every release/distribution job gates on $CI_COMMIT_TAG and a scheduled pipeline runs on the main branch ref. So the schedule's job is to create a tag, which then triggers the existing tag-driven release pipeline unchanged.

Changes

• scripts/release/create-release-tag.sh (new) — finds the latest vX.Y.Z tag, skips the week if there are only merge commits since it, otherwise bumps the version per Conventional Commits (a feat → minor, otherwise a patch) and creates an annotated tag via the GitLab API using glab.
• .gitlab-ci.yml
  • New tag-release job, gated on $CI_PIPELINE_SOURCE == "schedule" && $RELEASE_SCHEDULE == "true". Uses the registry.gitlab.com/gitlab-org/cli:latest image (already used by notify-issues-on-release).
  • Added the schedule source to workflow.rules.
  • Added a .skip-on-release-schedule guard to the heavy/side-effecting jobs (tests, builds, snapcraft edge) so the weekly schedule only cuts the tag — the resulting tag pipeline re-runs full validation and gates the actual release.
• docs/release_process.md — documents the automated flow and the one-time setup; the old steps are now under "Manual release".

Notes / review callouts

• Existing daily build is preserved. The skip guard keys on the RELEASE_SCHEDULE variable, not the generic schedule source — otherwise it would have disabled the daily main build's integration tests. The daily build doesn't set RELEASE_SCHEDULE, so it runs as before.
• Tag creation via API. The tag is created with glab api, authenticated by the existing GITLAB_TOKEN_RELEASE (passed as GITLAB_TOKEN). This keeps the token in the request auth rather than a git remote URL, and dogfoods glab in its own release pipeline. It must not be CI_JOB_TOKEN — tags created with it do not trigger a pipeline, so the release would never run.
• Versioning: a Conventional-Commits-based bump — a feat (incl. feat(scope):/feat!:) since the last tag bumps the minor version, otherwise it's a patch release. Major bumps are intentionally not automated (a deliberate v2 should be cut manually).

One-time setup for the automated release

These steps configure the project and cannot be done in this MR:

1. The tag-release job creates the tag with glab, authenticated by the existing GITLAB_TOKEN_RELEASE variable (passed as GITLAB_TOKEN to the job). That token already has api scope and the Maintainer role, which is sufficient to create a tag and trigger a pipeline. Do not switch it to CI_JOB_TOKEN — tags created with it do not trigger new pipelines, so the release would never run.
2. Ensure the user/bot backing GITLAB_TOKEN_RELEASE is allowed to create the protected v* tags (Settings → Repository → Protected tags).
3. Create a pipeline schedule (Settings → CI/CD → Pipeline schedules):
   • Description: Weekly release
   • Interval pattern: 0 7 * * 0 (every Sunday; adjust the hour/timezone as needed)
   • Target branch: main
   • Variable: RELEASE_SCHEDULE = true

🤖 Generated with Claude Code