test(spec): assert the AS derives provenance class from the accepted declaration

[tnunamak]

If the AS's provenance derivation regresses, a client reading the grant would see connector where the source is actually provider-native, and apply the wrong handling policy to real data without anything failing. Nothing in the tree would catch it. spec-core.md requires that a selection request does not carry source.kind at all: the AS derives the class from the declaration it accepted for source.id and records it on the grant, so a provenance-sensitive client can decide before it touches any resource.

The existing coverage in b3-introspection-resources-conformance.test.ts always sends kind in the request and only ever asserts kind === "connector". Neither the id-only request shape nor the provider_native class was covered.

What the evidence shows

Three tests, all passing. Two of them issue a grant end to end over HTTP against a real server on an ephemeral port, one per provenance class, and read the class back out of authorization_details and pdpp.source.kind. Since neither request carries kind, a correct class in the grant can only have come from the accepted declaration.

The third pins the refusal: an unknown source.id must return 400 naming it, not fall back to connector. That fallback is the default tail of the derivation chain in resolveAuthorizationDetailBindings, so without this assertion an unknown source would be silently classified.

Rewriting sourceBinding = acceptedSource in auth.ts to force kind: "connector" turns the provider-native test red, and restoring it turns it green. The test therefore depends on the derivation, not on a coincidence of fixture data.

3/3 on SQLite. 3/3 with PDPP_STORAGE_BACKEND=postgres against a scratch database. That run created 80 tables and left 2 rows in grants, so the Postgres path ran rather than skipping.

Scope

This adds one test file and changes no server code. A second oracle that shared this branch now lives in #117, which carries the server change that makes it green.

Assisted-by: AI

[tnunamak]

Rebase onto current main was blocked before the first signed commit: GPG opened interactive pinentry; cancellation caused signing to fail. The batch stopped under the requested GPG rule. This PR was not rebased. Head: 40d4f31 → 40d4f31 (unchanged). No new CI ran; existing checks show 7 success, 4 failure, 1 skipped. Needs work: unlock GPG and retry the rebase/CI verification.

Assisted-by: AI

[tnunamak]

Locally rebased onto main bac5526 with no conflicts: 40d4f31 → 027185f25291aefeee6dc4f2e4e1cae11850e886. Original patches are unchanged (range-diff and stable patch-ID comparison).

PARKED: unattended GPG signing failed with “No pinentry”. Rewritten commits have Tim’s identity and DCO but remain unsigned locally under the owner’s fallback policy; nothing was pushed. The remote head and its old hosted CI results are unchanged; no fresh hosted checks ran.

Preservation check: 5 passed, exactly the intended third trust-reliance oracle failed, 0 skipped. Both oracle files are unchanged. Intentionally red, decision pending; keep this PR draft and keep that test enabled.

Assisted-by: AI

[tnunamak]

These oracles cover two merged spec changes in pdpp: PDP-Connect/pdpp#311 (trust-registry queries and the reliance record) for the CIMD test, and PDP-Connect/pdpp#310 (provenance derived from the accepted declaration) for the provenance test.

Assisted-by: AI