ci: replace auto minor tagging with release-please

[leonardocarreras]

Replaces tag-minor-release with release-please.

tag-minor-release has never produced a release: it fails with fatal: empty ident name, actions/checkout sets no git identity. Fixing that alone would make it worse, since it cuts a stable minor on every master merge and derives the version only from git tag --list, never from CMakeLists.txt, python/pyproject.toml or doc/package.json (all 1.1.0 today, last tag v1.0.1). It also pushes the tag with GITHUB_TOKEN, whose events start no workflow runs, so push: tags: ["v*"] would never fire.

release-please opens a release PR that bumps all three files and maintains CHANGELOG.md; merging it is the release decision. In the first release CMakeLists.txt and doc/package.json show no diff, since they already say 1.1.0; leonardocarreras#3 is a bump where the numbers do move, and changes all five files. Version follows Conventional Commits, overridable with a Release-As: footer. The manifest starts at 1.0.1, so the first PR reconciles the drift and re-cuts 1.1.0.

Details:

• After tagging, the workflow dispatches ci.yaml at the new tag, workflow_dispatch being a documented exception to the GITHUB_TOKEN rule. is_version_tag is then true and deploy/release-nix run. No PAT needed.
• target-branch: master, so a manual dispatch cannot release unmerged code.
• The generated CHANGELOG.md carries no SPDX header and trips MD012, so it is annotated in REUSE.toml and excluded from markdownlint rather than weakening either for everything else.

Touches .pre-commit-config.yaml in a different place than #1034, so the two merge cleanly in either order. A follow-up, not here: the release page gives no hint that container images exist, since assets can only hold files.

Exercised end to end on my fork with this exact config: merging leonardocarreras#5 tagged and published v1.1.0, and the CI run it dispatched passed in full, attaching the ARX and RPM bundles to that release and moving latest and latest-nix.