feat(client): expose the credential type's FAQ on CredentialDescriptor

[rubenhensen]

What

clientmodels.CredentialDescriptor gains an optional Faq *Faq (faq,
omitempty), populated by every scheme-backed descriptor builder. Frontends
can then show the credential-specific explanation content (intro + FAQ cards)
in flows that only receive a descriptor — most notably when the user obtains a
missing credential during a disclosure session, which today falls back to a
generic one-liner (privacybydesign/irmamobile#668).

Closes #626.

How

The FAQ texts live on irma.CredentialType (FAQIntro / FAQPurpose /
FAQContent / FAQHowto), and every scheme-backed builder already holds that
object at construction time:

• CredentialType.ClientFaq() (new) converts the four texts to a
  *clientmodels.Faq, returning nil when the scheme provides none.
• Populated in client/schemaless.go — GetCredentialStore (descriptor-level,
  the item-level Faq stays for backwards compatibility),
  createCredentialDescriptor (issuance-during-disclosure bundles) and
  getCredentialDescriptor (wrong-credential templates) — and in
  eudi/openid4vp/irma_sdjwt_dcql.buildCredentialDescriptor (OpenID4VP DCQL
  obtainable descriptors).
• The generic EUDI DCQL handler intentionally stays nil: those credentials
  have no scheme entry, so no FAQ exists, matching the frontend's fallback
  rendering.

The field is additive JSON, so existing frontends are unaffected.
CredentialStoreItem.Faq is now redundant and can be deprecated once
frontends read the descriptor-level field.

Tests

• irma/descriptions_faq_test.go — ClientFaq converts all texts, keeps
  missing texts nil, and returns nil when no FAQ content exists.

go build ./... passes, go test passes for ./irma/..., ./client/...,
./common/... and ./eudi/openid4vp/..., and gofmt/go vet are clean.

[dobby-coder]

Thanks for opening this, Ruben! I'm on it — reviewing the new Faq field on CredentialDescriptor, the ClientFaq() conversion, and how it's wired through the schemaless.go and EUDI DCQL builders, then I'll leave a review with my findings.

[dobby-coder]

Reviewed by Dobby — looks good to merge.

Clean, additive change: the new faq field is omitempty, so existing frontends are unaffected, and CredentialType.ClientFaq() correctly returns nil when the scheme has no FAQ content. The four builders that hold a scheme-backed credential type all populate it; the generic EUDI DCQL path stays nil as intended. Test coverage for the all-texts, partial-texts, and no-content cases is present.

Checks passed:

• No ==/!= struct-equality traps (Go pointer-equality rule).
• PR title is conventional-commit; Closes #626 uses a valid closing keyword.
• Review-side findings: none; go build/test/vet/gofmt reported clean.

[dobby-coder]

Reviewed and approved this one — clean, additive change. The new faq field is omitempty so existing frontends are unaffected, ClientFaq() correctly returns nil when a scheme has no FAQ content, and all four scheme-backed builders populate it while the generic EUDI DCQL path stays nil as intended. Tests cover the all-texts, partial-texts, and no-content cases, and build/test/vet/gofmt are all clean. No blockers — good to merge.