chore(ci): pin the catalog at v6.0.0

manifold ran two catalog versions in one .gitlab-ci.yml: container, container-sign and verify at v4.0.2, release and binary at v3.0.0. Five pins, now all v6.0.0.

Why this is a manual bump

Renovate had detected both bumps and could not create either. Both sat in the Dependency Dashboard under Rate-Limited, behind the ten open MRs this project already carries against the shared preset's prConcurrentLimit: 10.

The preset gives catalog bumps prPriority: 10 so they are created first, but priority orders creation and cannot preempt MRs that already exist, so the bump could not arrive until a slot freed. Doing it directly removes it from the queue rather than waiting for one, and fixes the version split now.

Worth recording that this project was not broken. It was starved. The estate note this came from said manifold received zero Renovate MRs, and that was wrong: it receives ten, none of which was the catalog bump.

Verification

POST /projects/:id/ci/lint against this branch, with the branch content and dry_run: valid, no new warnings. The deprecated retry:when and multiple-pipelines warnings are pre-existing on main and unrelated to this change.

---

Updated to v6.0.0. This originally proposed v5.0.0. That tag shipped container with an image: that resolves to nothing, so every container build fails on buildah: command not found. Fixed in the catalog and released as v6.0.0, whose ci-buildah:v6.0.0 is published. Verified at runtime rather than by lint alone: kaniko's seven container jobs, which were exit 127 on v5.0.0, are green on v6.0.0.