Performs sign-then-encrypt operation: signs data with signKid, then encrypts
the resulting JWS with encryptKid to produce a nested JWE(JWS) structure.

Both keys must be homogeneous (both symmetric or both asymmetric). Both keys
must be different for security.

Serialization selection (PRD §60). The optional serialization field selects the representation of the INNER signed JWS (before it is encrypted into the outer JWE) and is orthogonal to the backend-authoritative RFC 3161 time-stamping policy (§49). Two honest compliance tiers apply to the inner JWS: RFC 7515 JWS (COMPACT = §7.1 three-segment compact, or JSON = §7.2 JWS JSON Serialization) and JAdES B-T (JWS JSON Serialization only, carrying an RFC 3161 qualified timestamp sigTst in the Unprotected Header per ETSI TS 119 182-1 — a COMPACT inner token structurally cannot carry it). Truth table (serialization × effective stamping → inner form): omitted+OFF → compact; omitted+REQUIRED → JWS-JSON + sigTst (auto-upgrade, JAdES B-T); COMPACT+OFF → compact; COMPACT+REQUIRED → 400 serialization-incompatible-with-timestamp (rejected BEFORE any signing or encryption); JSON+OFF → JWS-JSON, no sigTst; JSON+REQUIRED → JWS-JSON + sigTst. It never adds or drops a timestamp and does not change the outer JWE. The jweToken field and the separated sign/encrypt metadata envelope are ALWAYS present regardless of serialization.

Uses JWE General JSON Serialization (RFC 7516 §7.2) and JWS General JSON Serialization (RFC 7515 §7.2) uniformly across SIMPLE and COMPOSITE keys.
COMPOSITE keys enable hybrid post-quantum cryptography with dual signatures (COMPOSITE_SIGNATURE)
and combined key encapsulation (COMPOSITE_KEM_COMBINE).

Key type combinations:

• Symmetric + Symmetric (e.g., AES-GCM + HMAC-SHA256)
• Asymmetric + Asymmetric (e.g., ML-KEM + ML-DSA, RSA + ECDSA)
• COMPOSITE + COMPOSITE (e.g., COMPOSITE_KEM_COMBINE + COMPOSITE_SIGNATURE)
• COMPOSITE + SIMPLE (any homogeneous combination)

The JWE outer header includes cty="JWS" to indicate nested content.