shrink the promised surface: deprecate /v2/irma alias, drop dead format_version, unify x-postguard semantics

[rubenhensen]

Every exposed route, field, and header is a forever-commitment once unknown consumers depend on it. Shrink now, while breaking things means two conversations: deprecate and remove the /v2/{irma} alias (request is canonical), drop the dead format_version request field, and unify the three inconsistent meanings of the x-postguard header (with the envelope consolidation in the JS monorepo).

Gated on live client-version telemetry (privacybydesign/postguard-ops metrics scraping): announce in COMPATIBILITY.md → observe postguard_clients → remove.

Part of #247 (workstream F).

[rubenhensen]

Evidence for the /v2/irma half of this ticket, found while working #358 — worth recording because the oasdiff gate cannot see it.

The shipped pg-js still calls the aliases, not the canonical paths. Counted over packages/ and apps/ on postguard-js@main:

path	call sites
/v2/irma/sign/key	4
/v2/irma/key/	3
/v2/irma/start	1
/v2/irma/jwt/	1

The signing-key fetch is on the hot path for every seal: packages/pg-js/src/signing/yivi.ts:166, packages/pg-js/src/api/pkg.ts:44 and :128, plus tests/api.test.ts:84. Note the same file mixes conventions — startSession uses the canonical /v2/request/start — so this is drift rather than a deliberate choice.

Root CLAUDE.md already records that "the gate only sees paths the spec documents, and the spec documents canonical paths only, so dropping the /v2/irma/... alias handlers passes it." This is the consumer that would break, named. Dropping the aliases without a pg-js release ahead of it takes out sealing in the website and both add-ins, and api-diff.yml stays green throughout.

Suggests the removal needs a client-first sequence — repoint pg-js, publish, wait for the consumers to bump — rather than a single PR here.