Isolate the seal provider behind a SealBackend trait

[LKSNDRTMLKV]

Continues the module split landed in #106. That PR moved the provider's config, wire types, prose and tests into crates/dpp-seal/src/eideasy/, but two files still name the provider and both need a structural change rather than a text edit.

Remaining, measured

File	Mentions	What they are
src/adapter.rs	19	Backend::Eideasy, QtspSealAdapter::eideasy(), use crate::eideasy::client::EideasyClient
src/error.rs	11	variants encoding provider behaviour: five-minute HMAC skew window, rate-limit wording, "host is not this provider"
src/lib.rs	2	pub mod eideasy; and its doc link — structural, and the intended end state
src/config.rs	4	the selector's match arm — also intended

Scope

1. SealBackend trait, Box<dyn SealBackend> in QtspSealAdapter. Each backend module constructs its own; adapter.rs dispatches without naming any provider. Three implementors exist already — the hosted QTSP, local, and ghost — so the trait has real shape to answer to rather than being speculative.
2. Provider error variants move to eideasy/error.rs. SealError keeps only what is provider-agnostic (Config, Unsupported, transport). Safe to move: this crate is not published.

Done when

grep -rniE 'eideasy|eid.?easy' crates/dpp-seal/src --exclude-dir=eideasy returns only the pub mod declaration, its doc link, and the selector's match arm.

Context

• Design rationale and the option analysis: work/SEAL-ARCHITECTURE-2026-08.md in the docs repo
• What feat(seal): selectable backends, a local sealer, and profile split #106 already did, and why the local backend resolves to the Ghost trust tier while still draining: the PR body
• SealProvider is deliberately not #[non_exhaustive] — adding a backend must break every wiring site rather than fall into a _ arm

Not in scope

Passports recording which environment issued them. That is a field on a signed, retention-locked document in a published crate and needs its own design pass.

[LKSNDRTMLKV]

Done on feat/seal-backend-split.

SealBackend is the seam. QtspSealAdapter holds a Box<dyn SealBackend> and does nothing else: forward the port's three calls, and collapse SealError into DppError at the boundary. Each backend module constructs its own, so every wiring site reads QtspSealAdapter::new(...) and the adapter names none of them.

The provider error variants moved to eideasy/error.rs as EideasyError — Auth, RateLimited, Protocol, Provider, and AuthHint with the five-minute skew window. SealError keeps Config, Transport, Unsupported, plus a Backend(String) carrying a failure only the backend can describe, already classified and rendered where it happened. Nothing outside the crate ever matched on the variants, so flattening costs nothing and keeps provider vocabulary away from code that must stay ignorant of which backend is wired.

One thing beyond the stated scope, because the trait made it available: verify() is now the trait's default and it refuses. Previously the refusal was an arm in the adapter's match, which a new backend would have silently missed — a new implementor now has to override the default to claim a verdict at all.

The done-when grep returns exactly what the issue said it should — the pub mod, its doc link, and the selector's own references:

crates/dpp-seal/src/config.rs:71:            Some(crate::eideasy::config::PROVIDER) => Ok(Self::Qtsp),
crates/dpp-seal/src/config.rs:75:                crate::eideasy::config::PROVIDER,
crates/dpp-seal/src/config.rs:87:            crate::eideasy::config::ENV_GROUP,
crates/dpp-seal/src/config.rs:88:            crate::eideasy::config::any_env_set(get),
crates/dpp-seal/src/lib.rs:28://! - [`eideasy`] — a hosted QTSP backend: its config, wire types, client and errors
crates/dpp-seal/src/lib.rs:42:pub mod eideasy;

Also removed: QtspSealAdapter::config() and EideasyClient::config(), both unused, the first being the last thing in adapter.rs that named a provider type.