feat(crypto): add a coherent validated-provider and key-custody seam

[VerifiedOrganic]

Summary

The SDK has useful crate-local crypto seams (including the IKEv2
CryptoProvider), but it lacks one coherent runtime capability and key-custody
boundary through which a consumer can require a validated cryptographic module
for TLS, IKEv2, entropy, signatures/DH, and sealed key storage without leaving a
parallel unvalidated path active.

Verified against main at 709f4315443ed879f28c5d8524a019f7f1173587.

Current SDK evidence

• crates/opc-proto-ikev2/src/crypto.rs exposes a protected-payload
  CryptoProvider, while concrete IKE SA_INIT/key-derivation/signature/DH code
  also has direct algorithm implementations in the protocol crate.
• opc-key already provides KeyProvider/KeyHandle lifecycle APIs, and the
  protocol/TLS crates have their own seams. They do not share a provider
  identity, validated-capability report, self-test/readiness state, or a common
  way to bind those existing handles to one validated execution provider.
• A consumer therefore cannot prove at runtime that all security-critical
  operations are routed through the same approved provider, or fail admission
  when a required operation falls back elsewhere.

Requested change

• Define product-neutral provider traits/capability reporting for TLS,
  IKE PRF/integrity/encryption/signature/DH, approved entropy, zeroization,
  non-exportable/sealed keys, and provider self-test/readiness.
• Bind each capability report to a stable provider/module identity and version,
  with redaction-safe evidence suitable for readiness and release artifacts.
• Make algorithm policy explicit and fail closed when the selected provider
  cannot perform a required operation; no implicit software fallback.
• Integrate rather than replace the existing opc-key handle/lifecycle API;
  allow provider-owned non-exportable handles where a backend supports them.
• Permit a deployment to compose an ordinary non-validated provider without
  claiming validation, preserving existing developer/test use cases.

Acceptance criteria

• A test provider can satisfy the advertised TLS+IKE capability set through
  provider/key-handle APIs, with assertions that no direct parallel path ran
  for an operation admitted as validated.
• Removing any required capability fails startup/admission before network
  traffic is accepted.
• Key-generation, derivation, signing, and TLS private-key use can operate on
  non-exportable handles; diagnostics and Debug never expose key material.
• Provider self-test failure and loss of readiness withdraw the corresponding
  runtime capability and are observable through bounded, secret-safe evidence.
• Module name/version/validation-state evidence is available without asserting
  that the SDK itself certifies a deployment.

Non-goals

• Making a FIPS 140 or other certification claim for a consumer.
• Selecting a vendor/module, certification boundary, or deployment algorithm
  policy.
• Requiring validated mode for ordinary SDK users.

Consumer: downstream ePDG; this is release-profile dependent, not an immediate
interoperability blocker.

[VerifiedOrganic]

Reopening: only slice 1 of 5 has landed (#397). The phrase describing slice 5 in that PR body was parsed by GitHub as a closing directive.

Remaining work:

• slice 2: runtime admission gating so a missing required capability fails startup before listeners bind
• slice 3: IKEv2 binding
• slice 4: TLS binding
• slice 5: opc-key non-exportable handle custody

This issue closes when slice 5 lands.