decide: postguard-e2e's keyshare flow uses test.test.email, which #250's canonicalization registry does not match

[rubenhensen]

Question

Does the identity-canonicalization registry gain a test.test.email entry, or does postguard-e2e's keyshare disclosure flow move to a type the registry already matches — or is the e2e harness simply the wrong place to test this?

Split out of #336, where it sat as a trailing "related, same root" paragraph rather than the decision it actually is.

The facts

#250's RULES table in pg-core/src/identity.rs is keyed on the identity type's tail (sidn-pbdf.email.email), so pbdf., irma-demo. and any future scheme prefix match one entry. test.test.email — the credential postguard-e2e's keyshare disclosure flow issues and discloses (#238, postguard-e2e#40) — deliberately does not match, so the e2e harness never exercises canonicalization at all.

That was a choice in #250 rather than an oversight: a rule keyed on a test scheme's type would put a test-only entry in a table read on the PKG's production disclosure path.

The three answers, and what each costs

1. The registry gains a test entry. The e2e flow keeps its scheme and starts exercising the real rule. Cost: RULES carries an entry that exists only for a harness, and nothing stops it being cited as precedent for the next one.
2. The e2e flow moves to a matching type. Cheapest if the irma-demo scheme offers a keyshare-issuable credential whose type tail is sidn-pbdf.email.email — note root CLAUDE.md records that HINT_TYPES is missing its irma-demo email row, which implies such a type exists. e2e: keyshare-backed disclosure flow (test scheme + keyshare server) #238's flow currently issues test.test.email from an irmago checkout's schemes, so this needs checking rather than assuming. Cost: touching a flow that took three constraints to get working (irmago's internal/testkeyshare is unimportable, driver.go had to learn Status_RequestPin, and the ~6s sleep for irmaclient's PIN-auth cache).
3. Neither — the gap is a documented non-gap. Canonicalization is unit-tested in pg-core with vectors including idempotence, and the wire-level check is the wire-compat gate is blind to identity canonicalization: every sample value is already canonical #336's corpus case. If those two are the right layers, the e2e harness testing it as well buys nothing, and the answer is a comment in the flow saying so.

Done when

One of the three is chosen and recorded here. If it is 1 or 2, the change is on main with CI green; if it is 3, the note is in the harness.

Part of #247 (workstream C).