chore(pg-core): drop or replace the legacy irma 0.2.1 dependency

[rubenhensen]

pg-core 0.6.1 depends on the legacy irma crate at 0.2.1, so every consumer binary still compiles it in even after direct declarations were cleaned up (cargo tree -i irma → irma v0.2.1 ← pg-core ← {pg-pkg, cryptify, ...}) — encryption4all/cryptify#199 removed cryptify's dead direct dep and surfaced this root. It also drags reqwest 0.11 alongside the workspace's 0.13.

Not session-API drift (nothing in pg-core talks to a Yivi server through it — determine what it's actually used for: likely condiscon/attribute types), so the e2e compat manifest deliberately does not track it (encryption4all/postguard-e2e#28). This issue is the durable home for the follow-up instead.

Options, in rough preference order: drop it (vendor the few types), migrate to irmars 0.2.2 like pg-pkg did, or upstream a fix. Renovate (#254) and the cryptify merge spike (#255) will both bump into this — resolve here once.

Part of #247 (workstream F).

[dobby-coder]

/dobby fix — remove the legacy irma 0.2.1 dependency from pg-core.

Scope:

1. Find out what pg-core actually uses the irma crate for — cargo tree -i irma for the pull-in path, then grep the pg-core source for irma:: / use irma. It is likely only condiscon/attribute type definitions, not a Yivi session client.
2. Follow the issue's preference order: if the surface is a handful of types, vendor them into pg-core and drop the dependency. If it is genuinely a session/API surface, migrate to irmars 0.2.2 the same way pg-pkg already did — copy that crate's approach rather than inventing a new one.
3. Confirm the transitive reqwest 0.11 disappears from the workspace tree afterwards (cargo tree -i reqwest), and that the remaining consumers (pg-pkg, pg-wasm, cryptify) still build.
4. cargo fmt --all -- --check, cargo clippy and the full cargo test suite must pass before you push.

If step 1 shows this is a large API migration rather than a small vendoring or a pin swap, do not force it through — post what you found on this issue and stop. No postguard-e2e changes: the compat manifest deliberately does not track this one (see postguard-e2e#28).

[dobby-coder]

On it! I'm digging into why pg-core depends on irma 0.2.1 — checking cargo tree -i irma and grepping for irma:: usage to see if this is just a few condiscon/attribute types or a real session/API surface. From there I'll follow the issue's preferred fix (vendor the types, or migrate to irmars 0.2.2 like pg-pkg did) and make sure everything still builds and passes tests before opening a PR. If it turns out to be a bigger migration than expected, I'll report back on the issue instead of forcing it through.

[dobby-coder]

Parked: this is dobby-initiated work coupled to @rubenhensen, who already has 3 dobby PRs waiting for review (budget: 3). I'm not opening another one until some of those merge or close — comment here to re-trigger dobby once there's room.