[EPIC E4] Implement indexed-pull BGZ retrieval flow

[JorisHeadease]

Implement the complete indexed-pull BGZ retrieval chain and the result screens that make each Generic Function visible.

Work items

• Replace the stale /nvi/DocumentReference client path with the NVI List API.
• Query the NVI and render its localization output separately from GF Addressing output.
• Resolve the source endpoint through mCSD.
• Request the service access token through the Nuts node internal API.
• Retrieve the authorized resource-level BGZ data through the source PEP.
• Require explicit user confirmation before retrieval.
• Render the real top-level authorization result, the demo sub-check breakdown and disclaimer.
• Render the enriched record with explicit per-item source attribution and marker highlighting.
• Add a derived full-chain e2e test covering the combined flow.

Acceptance criteria

• One confirmation runs localization, addressing, authentication, authorization and retrieval end to end.
• NVI and GF Addressing results are visually distinct.
• No data is retrieved before explicit confirmation.
• Every retrieved element identifies De Zonnebloem as its source.
• Deny and failure paths expose no source data.
• The full-chain e2e test covers the happy path and an authorization denial.

Decisions required at kickoff

• Pin down the resource-level BGZ query set and aggregation behavior.
• Choose the source of the demo authorization sub-check breakdown while retaining the real top-level decision.

Frontend constraint

Use vendored Datastar as the initial frontend implementation. Keep backend routes, the step-event JSON schema, CSS/design tokens and the framework-free journey-map driver independent of Datastar. If the documented fallback triggers occur, the AI-assisted migration replaces Datastar with buildless Preact + htm in one cutover.

Depends on #540, #541, #542 and #543.

Refs #532
Refs #538

[JorisHeadease]

Picking up a boundary correction from #540, so it does not have to be rediscovered here.

#540's fourth acceptance criterion used to say the session must produce a token "that the PDP accepts". Authentication cannot deliver that on its own, for two reasons found while designing the credential slice.

The PDP does not accept a token. POST /pdp decodes an APIRequest whose input.subject is already introspection-shaped (component/pdp/component.go:86-98, component/pdp/shared.go:16-32). The PEP is what extracts the token, introspects it, and adapts the response into the request body (pep/nginx/js/authorize.js:203-304). Any test wanting a decision has to do the same, through the real PEP or a deliberate adapter.

Four of the seven Mitz inputs come from authentication; three do not. validateMitzInput requires patient BSN, data holder facility type and data holder organization ID from input.context, plus user id, user role, organization URA and organization facility type from input.subject (component/pdp/mitz.go:112-156). The first three are retrieval context: which patient, which source. That is this epic, and the patient comes from #542. A positive decision additionally needs a Mitz mock returning Permit and a request shape the BGZ policy allows (component/pdp/policies/bgz/policy.rego:9-46).

So #540 now ends at the four claims, asserted by introspecting the token. The decision belongs here.

What #540 hands over: a bgz scope in config/policy/bgz.json with three input descriptors, a plataan subject with an X509Credential in its wallet, and a client that requests and introspects a token.

Two things to know when building on it. The definition format block must allow the DeziIDJWT07 proof type or the derived Dezi credential falls outside the match (vcr/pe/presentation_definition.go:145-180, vcr/credential/dezi.go:83-109). And omitting token_type yields DPoP rather than Bearer (auth/api/iam/api.go:806-809), which means a possession proof bound to method, URL and token.

Related: #550 and #553 are both claim-mapping gaps that surface on this path.