fix(resolver): filter payload in its own scope

[LKSNDRTMLKV]

A restricted product-group field could have reached the public view. Based on #187, not on main.

What happened

The resolver filters a passport in two passes: the envelope with the passport-level policy, then productGroupData — removed from the envelope and handed on as its own root document — with the product group's policy.

The core library now scopes a product group's disclosure classes to that payload (dpp-core #183). That makes the second pass a caller that must declare its root is already inside the product group. Filtering it as an envelope applies none of that product group's classes and serves every restricted field in it.

Why this needed a new test

The wrong scope compiles, returns 200, and produces a body that looks right unless you know which field should be missing. Nothing in 864 tests caught it — the resolver's existing fixtures carry no restricted payload fields, so every audience saw the same thing either way.

There is now a test asserting an Annex XIII point 2 field (cathodeMaterial) is absent from the public response bytes. It was confirmed to fail with the wrong scope before being committed with the right one: a redaction test that has never been seen to fail proves nothing.

Same caveat as #187

CI cannot pass until core is released — this builds against unreleased core. Green locally against the sibling checkout.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 4 complexity · 2 duplication

Metric	Results
Complexity	4
Duplication	2

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}