seal: sealing is provider-locked in the composition root, not in the port

[LKSNDRTMLKV]

The problem

Sealing is provider-agnostic in the port and provider-locked in the composition
root. A self-hoster gets one specific QTSP or a ghost, and nothing in the design
requires that.

The port is already neutral. dpp_domain::ports::seal::SealPort says nothing
about any vendor. SealRequest, SealedEnvelope and SealFormat are
provider-neutral, and SealFormat already carries Cades, Xades, Pades and
Jades.

The wiring is not. QtspSealAdapter has exactly two states — the eID Easy
backend, or GhostSeal. dpp-node/src/main.rs selects between them by matching
on EideasyConfig::from_env(). There is no selector and no second backend.

So the constraint is roughly 200 lines of composition-root wiring, not an
architectural commitment.

Why this matters

A qualified certificate is issued to a legal person after identity
verification under eIDAS Art. 24(1). A self-hoster therefore cannot ride anyone
else's certificate — they must be their own subscriber. That makes "self-host
the software, then go contract with one specific vendor before you can publish a
compliant passport" the actual onboarding story, which is not a self-host story.

It is also worse for operators who already hold a relationship with a national
QTSP: they would be asked to re-procure through an aggregator that resells the
same underlying providers.

And it undercuts the positioning where it is strongest. The product is
operator-controlled infrastructure with no vendor lock-in; a hardcoded trust
provider is the one dependency that carries legal weight, and therefore the one
a compliance reviewer will notice first.

Shape

Cloud Signature Consortium (CSC) is the right interoperability target for a
second backend, rather than a third bespoke adapter.

• CSC API v2.2 defines the endpoints this needs: /credentials/list,
  /credentials/info for capability discovery, /signatures/sign/hash,
  /signatures/timestamp, and OAuth2 token issuance.
• Critically, it defines service-level authorisation for electronic seals —
  unattended signing with no per-signature activation step. That is the mode a
  passport-sealing node needs; the attended flows are designed for human
  signatures.
• It covers CAdES, XAdES, PAdES and JAdES, and distinguishes returning a raw
  signature from returning a full AdES envelope.

Sketch:

• Core — no change. The port is already right.
• dpp-seal — a provider selector plus a CSC backend alongside the existing
  one.
• Engine — near-zero. main.rs selects a backend instead of matching one
  config type; the sealing_live guard and the trust tier are unchanged.

What is not known

Per-vendor detail the specification cannot answer, and no public page states for
any candidate:

• which CSC version each QTSP actually serves;
• whether their service-authorisation mode is enabled for seals rather than
  only for attended signatures;
• their per-seal commercial terms.

Each of these needs a sandbox account per vendor to establish.

One thing to not carry forward

The csc/ module deleted alongside the eID Easy work is not a head start.
It modelled CSC v1.0, with a JAdES default this design would not use, against a
specification now several minor versions on. Reviving it means rewriting it —
the deletion stands.

Scope

This issue is the design and its cost, not a commitment to build it. It should
not start before the qualified-seal path is proven end-to-end against at least
one real provider, since a second backend written before the first one has ever
completed a live seal is a second untested thing rather than a hedge.

[LKSNDRTMLKV]

Partially addressed on feat/seal-backend-split. Recording what is done against this issue's own sketch, so what remains stays unambiguous.

• Core — no change. The port is already right.

Held. Nothing in the port changed.

• dpp-seal — a provider selector plus a CSC backend alongside the existing one.

Selector done, second provider not. SEAL_PROVIDER resolves to a SealProvider — deliberately not #[non_exhaustive], so adding a backend breaks every wiring site rather than falling into a _ arm — and each backend owns its own module, variables, validation and failure messages. Backends now sit behind a SealBackend trait with QtspSealAdapter holding a Box<dyn SealBackend> (#107).

The premise in the problem statement no longer holds: QtspSealAdapter has three states, not two, and the adapter names none of them.

• Engine — near-zero. main.rs selects a backend instead of matching one config type; the sealing_live guard and the trust tier are unchanged.

Done, and it was near-zero as predicted. main.rs dispatches on the selector rather than on a config type. sealing_live is now separated from the trust tier, because the local backend answers yes to "does this emit an envelope worth draining" and Ghost to "does this carry legal standing" — collapsing the two would either strand that backend unexercised or let a self-signed certificate satisfy a production boot.

What remains is the substantive half: a second real provider. The backend added so far is a local development sealer (#105), not a QTSP — so the onboarding story this issue objects to is unchanged for an operator holding a relationship with their own national QTSP. The wiring is no longer what stands in the way, which was this issue's central claim and is now demonstrably true: a CSC backend is a new module plus one arm in the selector.

Still gated on what the "What is not known" section already names — which CSC version each QTSP serves, whether service-level authorisation is enabled for seals rather than only attended signatures, and commercial terms. Each needs a sandbox account per vendor, and none of it is answerable from the specification.