tls: TLSSocket session deserialization failure leaves errors on the OpenSSL error queue (wrong error codes in later crypto calls) #67204

Version: v26.13.0 (also v24.22.2)
Platform: macOS arm64; OpenSSL 3.5.9

What steps will reproduce the bug?

// repro.mjs — run: node repro.mjs
import tls from 'node:tls';
import crypto from 'node:crypto';
const badPem = '-----BEGIN PRIVATE KEY-----\nAAAA\n-----END PRIVATE KEY-----';
const code = () => { try { crypto.createPrivateKey(badPem); } catch (e) { return e.code; } };
console.log('before:', code()); // ERR_OSSL_UNSUPPORTED
const session = Buffer.from(
  '006e6f64656a733a746c733a73657373696f6e3a31000014676174657761792e6578616d706c652e746573746d6f636b65642073657373696f6e',
  'hex',
);
const socket = tls.connect({ host: '127.0.0.1', port: 9, servername: 'gateway.example.test', session });
socket.on('error', () => {});
socket.destroy();
console.log('after: ', code()); // ERR_OSSL_ASN1_TOO_LONG (error left by d2i_SSL_SESSION)

What is the expected behavior? The same error code before and after. A session that cannot be deserialized should not leave errors on the OpenSSL error queue.

What do you see instead? after: ERR_OSSL_ASN1_TOO_LONG. The leftover error from d2i_SSL_SESSION is reported by an unrelated call.

Additional information

• Follow-up of webcrypto: valid AES-GCM decrypt aborts (errors->Empty()) after tls.connect() with an undeserializable session (v24.x) #67203, as suggested there. The abort itself is fixed by ae35a8f.
• TLSWrap::SetSession → GetTLSSession → d2i_SSL_SESSION does not clear or pop the error queue on failure (// TODO(tniessen): figure out error handling). Using ClearErrorOnReturn there, or throwing ERR_TLS_INVALID_SESSION, would avoid it.
• Seen in practice with a test HTTP interceptor that emits fake TLS sessions (Emulated TLS handshake emits undeserializable sessions; undici reuses them in tls.connect() (crashes Node ≤ 24 with WebCrypto) mswjs/interceptors#892), which undici then reuses.