docs(specs): record eparagony.pl API access + sandbox verification (#1907)

[norbert-kulus-blockydevs]

Records the outcome of the eparagony.pl vendor registration and the sandbox verification into the #1902 product spec. Documentation-only — no code, no schema, no runtime change.

What happened

Registration completed, credentials issued, and the sandbox verified by direct read-only calls. Nothing was created or mutated, and production was deliberately left untouched (a probe against login.eparagony.pl returns 401 invalid_client — the credentials are sandbox-scoped, as expected).

Probe	Result
POST login.sandbox.eparagony.pl/auth/token (client_credentials)	200 — bearer token, expires_in: 3600
GET sandbox.eparagony.pl/printers/{num}/status	200 — {"status":"INACTIVE",…}
same call without a token	401 Access denied — authorization enforced
GET /documents/{random-uuid}/status	400 errorCode: 92 — token accepted, document absent
GET /printers/{num}/reports/daily without report_fiscal_get	403 Forbidden — scope enforcement confirmed

What the spec now says

• New §3 subsection with the probe table, the granted scopes (document_create, printer_get, ecommerce) versus those refused at token issuance (document_get_jws, report_fiscal_get), the fact that the sandbox has no attached fiscal device — so it exercises the API contract but not device → eDPS → repository → webhook — and two documentation/reality drifts the adapter must tolerate (X-Api-Version / X-Integration-Id unenforced on GETs; an undocumented errorCode: 92).
• The stale bullet claiming docs and sandbox are "gated behind registration" is marked superseded rather than deleted, so the earlier research pass stays auditable.
• R3 marked ⏳ STILL OPEN. A sandbox is issued to Custom-API customers too, so technical access establishes nothing about pricing class. The multi-customer X-Integration-Id OL received is a supporting signal, not a classification.
• Three decision-log rows and a partial-progress note against [IMPL] Secure eparagony.pl integrator-class listing + API/sandbox access (BLOCKING, non-engineering) #1907 in §9.

What is still outstanding on #1907

Only the technical-access acceptance criterion is met. Still open, and all non-engineering:

• written confirmation of the pricing class (Integrator vs Custom API — worth 60–120 zł/mo per seller, permanently);
• a recorded decision on who builds the connector, us or them;
• partner-programme terms.

#1907 therefore stays open. Per the §9 sequencing #1908's design still runs in parallel, but the build-owner question should be pressed before #1908 moves from design into build.

How to review

Read the diff of docs/specs/product-spec-1902-eparagony-e-receipts.md. The probes are reproducible against the sandbox with the credentials held out-of-band; the mirrored vendor spec at docs/vendor/eparagony/ is gitignored and unchanged by this PR.

Refs #1907

🤖 Generated with Claude Code

[norbert-kulus-blockydevs]

Closing as superseded. This PR exists to unblock #1907 (secure eparagony.pl integrator-class pricing + sandbox access before building). #1907 is now closed — it got unblocked by finding eparagony.pl's public OpenAPI 3.0 contract instead, which let #1908/#2137 build and verify the adapter directly against the sandbox without waiting on the vendor conversation this PR was tracking. The live sandbox verification is now recorded in #2137's E2E evidence instead. No code or schema here, so nothing is lost by closing.