task: cut cryptify's Docker publish pipeline over to postguard, then retire the old repo's build

[rubenhensen]

Question

Cut encryption4all/cryptify's own Docker publish pipeline over to postguard's, so the old repo can safely archive later without killing production image delivery.

cryptify's ci.yml is today the only working publisher of ghcr.io/encryption4all/cryptify — it builds and pushes on every push to main, unconditionally. postguard's parallel pipeline (#280, merged) is built but inert: all three jobs (build-cryptify, scan-cryptify, finalize-cryptify) are gated if: vars.PUBLISH_CRYPTIFY_IMAGE == 'true', and that repo variable is unset.

Checklist (from #280's PR body, steps 1–4, deliberately deferred there)

1. Grant encryption4all/postguard Write on the existing cryptify GHCR package (package settings → Manage Actions access). Org-admin action; no workflow or API token in either repo can do this.
2. Set repo variable PUBLISH_CRYPTIFY_IMAGE=true on encryption4all/postguard.
3. Confirm the next push to postguard's main produces ghcr.io/encryption4all/cryptify:edge, and that a cryptify release also tags :0.1.x.
4. Retire encryption4all/cryptify's own ci.yml build/push steps (the build/finalize jobs), so two pipelines stop pushing the same tags.

Why this exists

Surfaced by #286 (part of #247). Archiving encryption4all/cryptify disables its Actions — no more pushes, no more triggered runs — so archiving before this lands would kill the only live image pipeline with no fallback. This ticket is what unblocks the archive step of the transfer-and-archive ticket for cryptify's issues.

[rubenhensen]

Steps 1–3 done, step 4's PR is open and waiting on review before merge.

1. GHCR Write grant — done (org-admin action you took directly).
2. Repo variable — done differently than the checklist assumed: instead of setting PUBLISH_CRYPTIFY_IMAGE=true, the if: gate was removed from the workflow entirely, so the jobs are now unconditional (postguard#309, merged as 506144c). Deliberate choice, made with you: costs the instant-off-switch a variable would have given, in exchange for not needing a later cleanup PR to remove the variable.
3. Confirmed the next push produces the image. 506144c triggered Delivery; build-cryptify (amd64+arm64), scan-cryptify, and finalize-cryptify all succeeded — job log shows pushing sha256:285aab... to ghcr.io/encryption4all/cryptify:edge, no errors.
4. PR open, not yet merged: cryptify#206 retires the build/finalize jobs from encryption4all/cryptify's own ci.yml (also drops the version-output plumbing that only finalize consumed). Left quality and release-plz-release/release-plz-pr untouched — out of scope here. Holding off merging until you've looked at the diff, since this removes cryptify's last independent Docker publish path — once merged, postguard's pipeline is the only one left, with no quick revert short of reverting the PR.

Note: this repo's own release-plz-release/release-plz-pr jobs are still active and were what produced #161 (the "release v0.1.28" PR closed as superseded in #294). Whether that release-plz instance should also be retired now that the crate releases through postguard's workspace release-plz is a real question, but it's outside this ticket's checklist — flagging it rather than acting on it.

[rubenhensen]

All four steps done, closing.

1. GHCR Write grant on the cryptify package — done (org-admin action).
2. Repo variable equivalent — the PUBLISH_CRYPTIFY_IMAGE gate was removed entirely rather than flipped, so build-cryptify/scan-cryptify/finalize-cryptify run unconditionally (postguard#309, merged 506144c).
3. Confirmed: 506144c produced ghcr.io/encryption4all/cryptify:edge — finalize-cryptify's log shows the push landing with no errors.
4. Retired encryption4all/cryptify's own build/finalize jobs (cryptify#206, merged a361e6a). Verified the resulting main CI run: quality, release-plz-release, release-plz-pr all green, no Docker jobs left to fail.

postguard's pipeline is now the sole publisher of ghcr.io/encryption4all/cryptify. This unblocks #294's archive step (step 7), which was waiting on this.

Left alone, flagged but out of scope here: cryptify's own release-plz-release/release-plz-pr jobs are still active and still the ones producing release PRs/tags for this repo, separate from the crate's release through postguard's workspace release-plz. Worth a decision at some point, not bundled into this ticket.