SealPort must not assume a single trust provider

[LKSNDRTMLKV]

The assumption to remove

SealPort is a port, which is right. But the surrounding design has been shaped around one provider's API and one account holding one certificate. Two things follow from that which should not:

1. One provider. Advanced-signature profiles differ between providers — some return CAdES only, some also XAdES, ASiC or JAdES. A port whose contract silently assumes one profile is not a port.
2. One certificate holder. The obligation to keep passport content accurate sits with the economic operator placing the product on the market, and the regulation explicitly permits them to authorise another party to act on their behalf. So the certificate naming them, operated by us under that authorisation, is a lawful and arguably more honest arrangement than one certificate covering everyone.

A seal attests the origin of what it covers. Whoever holds the certificate is making a claim about content they may not have authored.

Scope

• The port contract expresses which signature profile is being requested and refuses one it cannot produce, rather than assuming.
• Resolution of which certificate signs a given passport is an input, not a global. A per-operator holder must be expressible even if the first deployment uses one.
• No provider-specific vocabulary in the port. Provider quirks belong in the adapter.

Why now rather than later

Certificate holder is not a configuration detail — it changes what the seal means, and it is baked into every passport issued under it. Retention lock means a sealed passport cannot be re-sealed.

Related: #123 (whether the seal signs the payload or wraps it), #124 (local implementation).