feat(cryptify): merge cryptify into the workspace

[rubenhensen]

Closes #255. The decision comment on that issue has the full spike writeup and the measurements; this is the change it recommends.

cryptify becomes a workspace member, compiled against the in-tree pg-core. All 402 of its commits come across as a history-preserving subtree merge.

Why

Today postguard builds pg-core against bincode-next 3.0.0-rc.14 and cryptify builds pg-core against bincode-next 3.1.1, because each repo resolves its own lockfile. Same source, two versions of the serializer that writes the container header, in two services that exchange containers, with nothing comparing them. CLAUDE.md's rule (pin the exact rc, re-audit on any bump) is not reaching cryptify's copy.

That is benign right now, and provably so: pg-compat's lockfile is also on 3.1.1, so the green wire-compat check already demonstrates rc.14-sealed bytes opening under 3.1.1. But it falls out of another gate's dependency resolution by accident, and the next bincode bump is unguarded. One workspace is one lockfile, and the #127 memory-vs-stream class becomes a PR-time test failure rather than a cross-repo surprise.

The price

libsqlite3-sys sets links = "sqlite3" and only one package per resolve graph may claim it. pg-pkg reaches it through sqlx, cryptify through rusqlite. Optional deps are in the graph regardless of features, so pg-pkg pulls sqlx-sqlite in despite enabling only postgres.

sqlx-sqlite 0.9.0  wants libsqlite3-sys >=0.30.1, <0.38.0
rusqlite    0.40.1 wants libsqlite3-sys ^0.38.1

Empty intersection. The newest pair that intersects is sqlx 0.9 + rusqlite 0.39, so this PR carries both. pg-pkg needed no source changes for sqlx 0.9.

The standing cost, and the part worth a deliberate yes: every future rusqlite bump now waits on sqlx's libsqlite3-sys ceiling. cryptify is already one release ahead of what sqlx permits.

What else had to change, and why

• cryptify/build.rs read Cargo.lock beside its manifest to stamp PG_CORE_VERSION into the X-PostGuard header. A member has no lockfile there, so it now walks up from CARGO_MANIFEST_DIR.
• api-diff.yml covers both specs via a matrix, not two jobs. pg-pkg/tests/api_gate.rs and cryptify's mod api_gate_tests each require exactly one fail-on: and one include-checks: line in that file, so neither can claim a setting the committed job does not use. Two oasdiff steps would give two of each and fail both suites.
• build.yml's matrices key on the crate directory instead of a pg- prefix, which renames the Test/Format/Clippy workspace (…) contexts. Only the two Wire compat contexts are required on main, so nothing breaks, but a ruleset added later needs the new names.
• Both Dockerfiles. cryptify's builds from the repo root now. postguard's needed COPY cryptify (cargo-chef loads every member's manifest even for a build that never compiles it) and its Rust pin moved 1.91.1 → 1.96.1, because sqlx 0.9 declares rust-version = 1.94.0. Both of those passed the whole test matrix on host stable and failed only in Docker.
• cryptify's own .github/, Cargo.lock and release-plz.toml are gone, replaced by an entry in the root release-plz.toml.

Verification

Run locally on this branch, mirroring build.yml's per-crate invocations:

lane	result
pg-core (test,rust,stream)	pass, 18s
pg-pkg (all-features)	pass, 29s
pg-cli (all-features)	pass, 17s
pg-ffi (all-features)	pass, 10s
cryptify (all-targets)	157 tests pass, 27s
cryptify clippy -D warnings	pass
cargo fmt --all --check	pass
wire-compat (seal with HEAD, open with published pg-core)	pass

Both images build: docker build . and docker build -f cryptify/Dockerfile ..

Deliberately not in this PR

Image publishing still comes from the cryptify repo. delivery.yml's Docker jobs push to ghcr.io/${{ github.repository }}, so publishing cryptify's image from here means either renaming it away from ghcr.io/encryption4all/cryptify or changing that package's GHCR access. Either affects whatever pulls it, so it is an ops decision rather than a mechanical port.

That makes this a coherent intermediate state, not a half-finished one: postguard becomes source of truth for the code and gets the one-lockfile guarantee immediately, while the cryptify repo keeps building and pushing images exactly as it does today. Decommissioning it is a follow-up, and it needs privacybydesign/postguard-ops in the loop.

Also outstanding: release-plz will treat cryptify as an initial release. A subtree import brings commits, not tags, and the old tags were bare v0.1.27 against this workspace's cryptify-v{version} pattern. Without a hand-placed cryptify-v0.1.27 tag on the import commit, the first changelog entry covers all 402 imported commits. Worth doing before this lands on main.

Reviewing this

The subtree merge makes the diff large. git diff main...HEAD -- . ':!cryptify' is the 8-file change to the existing tree; everything under cryptify/ is imported as-is apart from Cargo.toml, build.rs, Dockerfile and the one include_str! path in src/main.rs.