Add TEE support (Intel SGX/AMD SEV) for confidential compute

[flo2517]

Run workloads inside hardware enclaves (Intel SGX, AMD SEV) so that a provider hosting a workload cannot read its memory or data. This is the structural answer to the Byzantine-provider problem that stake and reputation only mitigate: ADR-012 §2 lists operator-level collusion as unsolved, and confidential compute is what eventually closes it.

Blocked by: ADR-019 (see ADR-012 §6) — no implementation before acceptance. #61 provides the proof that this issue's guarantee is real; the two ship together or the guarantee is unverifiable.

Acceptance criteria:

• ADR-019 states which vendor roots of trust are accepted, the revocation path when one is broken, and what an unattested provider may still do;
• TEE capability is advertised as a distinct, verifiable resource property, and a tenant can require it as a scheduling constraint;
• a workload requiring a TEE never runs outside one — failure to place is an explicit scheduling failure, never a silent downgrade to plain execution;
• the trusted computing base is documented, including what the provider can still observe (scheduling, traffic volume, timing) despite the enclave;
• secrets reach the enclave without the provider seeing them, and key release is bound to a successful attestation from Add a distributed enclave attestation protocol #61;
• known TEE limitations — side channels, rollback attacks, vendor key compromise — are documented as residual risk rather than claimed to be solved;
• TEE support is opt-in per workload and never network-wide, preserving the rollback property required by ADR-012 §7;
• tests cover placement on an attested provider, refusal to place when none is available, a provider falsely advertising TEE support, a revoked vendor root, and secret release denied on failed attestation.

---

Original request (FR, preserved verbatim):

Permettre l'exécution des workloads dans des enclaves sécurisées pour garantir la confidentialité des données.