ci: weekly SemVer releases with generated notes; freeze CHANGELOG.md at 1.7.4 (#800)

* ci: publish a weekly SemVer release with GitHub-generated notes

Every Monday at 06:00 UTC the workflow tags master and publishes a GitHub
Release whose notes list the merged PR titles. tools/next_version.py picks the
version from the commits since the last release: type!: or a BREAKING CHANGE
footer is major, feat is minor, anything else is patch. A manual run can
override it. Weeks without commits are skipped, a master commit whose CI did
not pass is never released, and forks never run it.

* docs: point contributors and forks at weekly GitHub Releases

PR titles are now the release notes and their type sets the version, so
CONTRIBUTING and the PR template say so. README and SETUP describe releases
as weekly checkpoints that passed CI instead of pointing at CHANGELOG.md.

* chore(changelog): freeze at 1.7.4 and fail PRs that still edit it

Rolls [Unreleased] into [1.7.4] and rewrites the intro to point at GitHub
Releases. The structure test becomes a content pin: stale PRs carry entries
that git would merge cleanly into the frozen section, so any edit now fails
CI with a pointer to the PR title.

* fix(release): address review findings on the weekly release

Write access moves to the job; the override rejects existing or older
versions; next_version.py reports a missing tag instead of a traceback and
drops the unused rev argument; tests pin the fork guard and SHA-pinned
checkout. The frozen changelog drops the date written ahead of the release,
describes its guard accurately, and the guard skips on forks.

* chore(changelog): re-pin the frozen hash after rebasing onto master

* ci(release): compute the version with commitizen via setup-uv instead of an in-repo script

A week of only docs, chore or ci commits now ships nothing on its own, matching commitizen's conventional-commit bump rules; fix, refactor and perf bump patch.

SETUP.md

@@ -305,7 +305,7 @@ These commands apply to the stock templates (moderncv CV, `cover.cls` cover lett
 
 Upstream keeps improving the methodology files your fork has personalized, so plan for updates from day one:
 
-**Prefer releases over raw `master`.** Tagged [releases](../../releases) are vetted checkpoints, each described in [CHANGELOG.md](CHANGELOG.md). Updating to a tag pulls a stable, documented state instead of whatever `master` happens to be mid-review. Fetch tags with `git fetch upstream --tags` and merge a release (for example `git merge v1.0.0`) when you want stability; pull `master` directly only when you specifically want the latest unreleased changes. The steps below apply either way - substitute the release tag for `upstream/master` where you see it.
+**Prefer releases over raw `master`.** Tagged [releases](../../releases) are weekly checkpoints of `master` that passed CI, each listing the PRs it contains on its release page ([CHANGELOG.md](CHANGELOG.md) covers releases up to 1.7.4). Updating to a tag pulls a stable, documented state instead of whatever `master` happens to be mid-review. Fetch tags with `git fetch upstream --tags` and merge a release (for example `git merge v1.0.0`) when you want stability; pull `master` directly only when you specifically want the latest unreleased changes. The steps below apply either way - substitute the release tag for `upstream/master` where you see it.
 
 1. **Commit your personalization - but know where those commits land.** `/setup` edits CLAUDE.md and the profile skill files in place; those edits are *yours*, and committing them is what lets updates merge cleanly. But a GitHub **fork of this repo is public** - forks of public repositories cannot be made private - so anything you commit *and push to a fork* is visible to anyone. If you want your profile in a remote at all, don't push it to a fork: create a **private** repository, push there, and add this repo as the `upstream` remote (`git remote add upstream https://github.com/ai-job-search-dev/ai-job-search.git`) to keep receiving updates. Committing locally without pushing is also fine. The genuinely sensitive files (tracker, salary data, `documents/`, application archives) are gitignored and never enter git either way. An uncommitted working tree is the most common reason `git pull` refuses to merge at all (`Your local changes ... would be overwritten`).
 2. **Preview what changed before pulling:**