ci(cryptify): publish the cryptify image from this repo

[rubenhensen]

Starts moving cryptify's image delivery into this repo now that the crate lives here. Refs #255.

Adds build-cryptify, scan-cryptify and finalize-cryptify to delivery.yml, mirroring the existing pg-pkg jobs, plus a cryptify_version output on release-plz-release so a release tags the image the way pg-pkg's does.

Merging this changes nothing that runs today

All three jobs are gated on a repo variable:

if: vars.PUBLISH_CRYPTIFY_IMAGE == 'true'

Unset, they skip. That gate is load-bearing rather than decorative, see below.

The decision this PR does not make

The image keeps the name the cryptify repo publishes today:

env:
  CRYPTIFY_IMAGE: ghcr.io/${{ github.repository_owner }}/cryptify

so nothing that pulls ghcr.io/encryption4all/cryptify has to be repointed. That requires granting this repository push access to the existing GHCR package — package settings → Manage Actions access → add encryption4all/postguard with the Write role. No workflow can set that, so it cannot happen in this PR, and I could not verify the package's current settings either (this token lacks read:packages).

Until that access exists the push would fail and turn delivery red on every push to main, which is why the jobs are gated rather than merged live.

The alternative is publishing under a new name. That needs no package settings change but moves the work to every deployment that pulls the image, which is privacybydesign/postguard-ops territory. Changing the one env: line above is the whole cost of going that way instead.

Turning it on

1. Grant encryption4all/postguard Write on the cryptify GHCR package.
2. Set repo variable PUBLISH_CRYPTIFY_IMAGE=true.
3. Confirm the next push to main produces :edge, and that a cryptify release also tags :0.1.x.
4. Then, separately, retire the cryptify repo's own build so two pipelines are not pushing the same tags.

Step 4 is deliberately not here. Until it happens both repos publish, which is redundant but not harmful, since both build the same source from the same lockfile.

Notes

• build-cryptify uses the repo root as build context with file: cryptify/Dockerfile, because a workspace member cannot be built without the root manifest and its siblings.
• The SARIF upload uses category: cryptify so it does not collide with the pg-pkg scan's results.
• Purely additive: 165 insertions, no deletions, pg-pkg's jobs untouched. actionlint reports no workflow or expression errors; its shellcheck notes on the new jobs are the same ones the existing jobs already carry, kept for consistency.