feat(client): surface all accepted DCQL claim values via requested_values

[rubenhensen]

What

clientmodels.Attribute gains RequestedValues []AttributeValue
(requested_values, omitempty) carrying all values the verifier accepts
for an attribute, in the verifier's order. Previously only the first entry of
a DCQL claim's values array reached the frontend via the single
requested_value field.

OpenID4VP DCQL (section 6) lets a verifier accept several values for one
claim, of which the holder must disclose one. The wallet locks its embedded
obtain flows to the verifier-requested values (privacybydesign/irmamobile#583)
and offers a choice when several are accepted — which needs the full list.

Closes #625.

How

• requested_value keeps duplicating the first accepted value, so existing
  frontends are unaffected (documented on both fields).
• Populated in:
  • irma_sdjwt_dcql.buildCredentialDescriptor — OpenID4VP DCQL obtainable
    descriptors (the flow behind the wallet's obtain-during-disclosure).
  • eudi_sdjwt_dcql.queryAttributes — unobtainable descriptors for generic
    EUDI credentials, which previously surfaced no requested values at all;
    the user now sees which values the verifier asked for.
  • client.createCredentialDescriptor — classic-IRMA issuance-during-
    disclosure bundles. The IRMA protocol allows a single required value, so
    this is a one-element list; populating it means frontends can read one
    canonical field regardless of the session protocol.
• Matching of owned credentials against the accepted values already worked
  and is unchanged.

Tests

• irma_sdjwt_dcql: new case in TestDcqlCandidateSelection — an
  unsatisfiable query with two accepted values yields an obtainable
  descriptor carrying both values in order, with requested_value
  duplicating the first.
• eudi_sdjwt_dcql: TestComposeUnobtainableDescriptor_ValueConstraints —
  same assertions for the generic EUDI unobtainable descriptor.

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

[dobby-coder]

Thanks for the PR! I'm reviewing #629 now — checking the new RequestedValues field and its population across the DCQL and classic-IRMA descriptor paths for correctness and rule-compliance. I'll follow up shortly with a consolidated review.

[dobby-coder]

Looks good — approving.

Additive, backwards-compatible change: RequestedValue keeps duplicating the first accepted value while the new requested_values (omitempty) carries the full verifier-ordered list. Verified:

• All three population sites are correct. In both DCQL handlers the loop builds RequestedValues from the string entries of claim.Values, and RequestedValue is derived from the first element — no shared-pointer or loop-variable aliasing issues (each &s is a fresh per-iteration variable, and queryAttributes copies first to a local before taking its address).
• client/schemaless.go builds the one-element list from the single IRMA required value, giving frontends one canonical field across protocols.
• No struct ==/!= comparisons, so the Go pointer-equality trap doesn't apply.
• Tests cover both the obtainable (irma_sdjwt_dcql) and unobtainable (eudi_sdjwt_dcql) paths, asserting order preservation and the requested_value duplication.
• Closes #625 is correctly formatted and targets master, so it will auto-close on merge.

[dobby-coder]

Reviewed and approved! I checked the population sites in irma_sdjwt_dcql.buildCredentialDescriptor, eudi_sdjwt_dcql.queryAttributes, and client.createCredentialDescriptor — no shared-pointer or aliasing issues, and the tests cover both the obtainable and unobtainable descriptor paths correctly. The Closes #625 reference is also correctly formatted. No blocking issues from me.

#629