Align presentation definition filter evaluation with JSON Schema semantics

[stevenvegt]

Context

PEX defines a field's filter as a full JSON Schema (our own wire schema declares it as a draft-07 $ref), but matchFilter in vcr/pe implements a subset with semantics that deviate from JSON Schema. The load-time validator added in #4281 documents and flags the consequences (see the filter-semantics section in the Validate godoc), but the underlying evaluation is unchanged. This issue tracks the deliberate decision whether and how to align.

Current deviations

1. enum shadows every other keyword: type, const and pattern are not evaluated when enum is set. JSON Schema ANDs all keywords.
2. Filter.Const and Filter.Enum are string-typed in Go: spec-valid numeric or boolean consts fail at parse with an unmarshal error, and values compare as strings only.
3. pattern is only evaluated when type is "string"; JSON Schema applies keywords per value type (a number trivially passes pattern).
4. Numeric keywords (minimum, maximum, multipleOf), minLength, format and composition (allOf, anyOf, not) are not implemented. Since [#4253 2/8] feat(pe): PD validators (Validate + ValidateSelectionKeys) #4281 they are rejected by pe.Validate for own policy files instead of being silently dropped; remote PDs still parse leniently and match weaker than declared.
5. Consequence of 1-4: numeric claim values cannot be value-constrained at all. Documented guidance is to issue filterable claims as strings.

Considerations

• The evaluation machinery is already vendored: santhosh-tekuri/jsonschema validates the PD documents themselves (vcr/pe/schema/v2). Filter-level evaluation would be wiring, not a new dependency, and schemas can be compiled once at PD load.
• The capture-group value extraction in matchFilter is a documented feature (docs/pages/deployment/policy.rst, "Extracting substrings with regular expressions") with no JSON Schema counterpart. Any alignment must preserve it or provide a migration.
• Changing filter semantics changes live matching behavior for counterparty-supplied PDs as well as own policies; this needs release notes and possibly a compatibility window.
• Ecosystem context: OpenID4VP 1.0 replaces PEX with DCQL. Decision 2026-07-16: PEX field matching stays (DCQL is less expressive for our field-binding use); eventual dual support is an option. That bounds how much to invest here.

Relates to #4253 (the selection engine consumes filter evaluation results; pe.Validate encodes the current semantics and must be updated together with any change here).