docs: pin registry rules to the OJ text, release 0.10.0

[LKSNDRTMLKV]

Upgrades every registry claim in this repo from secondary-source to
primary-source, read directly from the Official Journal text of Commission
Implementing Regulation (EU) 2026/1778. Documentation only — no code changes.

Why

The previous commit landed the registry go-live correction but had to mark its
article-level detail 🟠, because EUR-Lex refuses automated retrieval (HTTP 202
with an empty body to non-browser clients). Reading the OJ text directly both
confirmed most of it and narrowed one claim that was overstated.

What the OJ text settles

• Who may register, and on what credential. A verified economic operator
  places the registration (Art. 8(1)); for a legal person, verification rests on
  a qualified electronic seal supported by a QTSP-issued qualified certificate,
  or a qualified electronic attestation of attributes (Art. 4(2)).
• Establishment in the Union is not a precondition. Arts. 4(2)(b) and
  5(2)(b) provide expressly for parties not required to be so established.
• Third-party registration is permitted where the operator authorises it and
  the third party completes the Art. 5 value-chain-actor verification
  (Art. 19(4)) — and the operator "shall remain fully responsible for compliance
  with the obligations set out in this Regulation", remaining controller of the
  data it submits (Art. 19(5)). SealMode::ProviderSeal is documented
  accordingly: it moves the mechanics, never the liability.
• Registry structure (Art. 3): an API for registration and retrieval
  (Art. 3(b)), a list of verified DPP service providers (Art. 3(f)), and storage
  of identifiers and commodity codes (Art. 3(e)).
• Granularity and linking (Art. 8(1), (3)–(5)) and the automated checks
  applied on submission (Art. 8(7)).

Correction

The previous entry stated commodity code "appears in registration and its
validation" without qualification. The text scopes it to products intended for
the customs procedure "release for free circulation" (Art. 3(e)), validated
where relevant (Art. 8(7)(d)). Still a real gap in our model — it is absent
entirely — but conditional on the customs path rather than universal. Narrowed
in COMPLIANCE.md, dpp-registry, and the changelog entry.

Verification

Full gate green: fmt, clippy --all-features, tests --all-features, doc,
audit.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.

_{TIP This summary will be updated as you push new changes.}

[codacy-production]

Pull Request Overview

The PR successfully aligns the repository's compliance documentation and crate-level comments with the official primary-source text of Commission Implementing Regulation (EU) 2026/1778. The implementation correctly identifies structural divergences in the registry crate and updates credential requirements to reflect the latest legal standards. Codacy analysis indicates the changes are up to standards with no new quality issues. One documentation inaccuracy regarding the specific paragraph citations for third-party registration liability in the seal port definition requires correction to ensure legal precision.

1 comment outside of the diff

crates/dpp-domain/src/ports/seal.rs

_{line 139 🟡 MEDIUM RISK}
The article citations for the third-party registration rules are slightly misaligned. IR 2026/1778 Article 19(4) establishes the right to authorize a third party, whereas Article 19(5) contains the clauses regarding the operator's continued responsibility and status as the data controller. Move the citation of Article 19(4) to the sentence regarding third-party authorization (at line 137), and update the citation for the 'fully responsible' and 'controller' clauses to Article 19(5) (lines 139-140).

Test suggestions

• Verify that SealMode::ProviderSeal documentation correctly identifies third-party registration rights and operator liability retention per Art 19.
• Verify that dpp-registry crate documentation lists the lack of commodity codes and identifier-linking as known divergences.
• Verify that RegistryEndpoint documentation identifies the structural mismatch between the existing bearer-token model and the required eIDAS-based auth.
• Verify that compliance documentation reflects that EU establishment is not a registration precondition.

_{TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback}

[codacy-production]

_{⚪ LOW RISK}

Nitpick: This sentence is missing a trailing period. ```suggestion
//! the EU Registry Readiness section of [REDACTED:HIGH_ENTROPY].

<!-- e34d5167-b092-49eb-b8c8-33859ab00079 -->

[LKSNDRTMLKV]

Added the release commit: workspace bumped to 0.10.0 and the changelog's [Unreleased] section closed as [0.10.0] - 2026-07-20.

0.10.0 rather than a patch because the section carries a Breaking entry — lintResult leaving the Public access tier. Per VERSIONING.md, a pre-1.0 minor may contain breaking changes with a migration note, which is what that entry provides.

Verified before pushing: fmt, clippy --all-features, tests --all-features (all suites green), doc, audit. cargo package --list -p dpp-domain confirms all 20 embedded schema files are included, so the include_str! packaging trap is clear.

Note the two open dependabot PRs (#36, #37) are not included — both are based on the pre-#42 main and are failing Clippy and Tests. They need rebasing and re-evaluating on their own, especially #37, which moves a runtime schema-validation dependency.