Fix TLS 1.3 CertificateVerify transcript hash length (use ciphersuite hash)

[EdouardMALOT]

Summary

Follow-up to the #377 review discussion (#377 (comment)):
the dynamic transcript-hash length introduced there is keyed to the signature scheme's
hash, but per RFC 8446 §4.4.3 the
CertificateVerify content embeds Transcript-Hash(Handshake Context), whose length is fixed
by the negotiated ciphersuite's hash. The two differ whenever a peer signs with a hash
other than the suite's.

Concrete case with the only TLS 1.3 suite currently enabled (TLS_AES_128_GCM_SHA256):
an ECDSA P-384 certificate signs ecdsa_secp384r1_sha384, so 48 bytes are copied from a
32-byte transcript-hash slot (nx_secure_tls_transcript_hashes[..][NX_SECURE_TLS_MAX_HASH_SIZE]
with NX_SECURE_TLS_MAX_HASH_SIZE == 32). This corrupts the signed content on the send side
and rejects valid peer signatures on the verify side — TLS 1.3 no longer works with ECDSA
P-384/P-521 certificates (it did before #377, when the copy length was a constant 32,
which was correct for every configuration shipped at the time).

The concern raised in the review remains fully addressed: the length is not hardcoded, and
SHA-384/512 ciphersuites will produce 48/64-byte transcript hashes when they are enabled.

Changes

• nx_secure/src/nx_secure_tls_send_certificate_verify.c — key the transcript-hash copy
  length to nx_secure_tls_session_ciphersuite -> nx_secure_tls_hash (SHA-256 fallback,
  mirroring _nx_secure_tls_1_3_transcript_hash_save). The signature scheme's hash still
  digests the assembled content and parameterizes RSA-PSS.
• nx_secure/src/nx_secure_tls_process_certificate_verify.c — same fix on the verify side.
• test/regression/nx_secure_test/nx_secure_tls_1_3_certverify_transcript_hash_test.c —
  regression test calling both functions directly with a signature-scheme hash (SHA-384) that
  differs from the ciphersuite hash (SHA-256), capturing via a spy hash method the exact byte
  count copied into the CertificateVerify content. Asserts 32 bytes (ciphersuite SHA-256,
  correct), not 48 (signature-scheme SHA-384, what the bug copied).

Test plan

• Regression test added, exercising both the send and process paths directly
• Verified against real hardware: a NetX Duo TLS 1.3 client repeatedly and reliably
  completes the handshake against a broker presenting EC P-384 and P-521 server
  certificates (ecdsa_secp384r1_sha384 / ecdsa_secp521r1_sha512), where it previously
  rejected the broker's valid CertificateVerify signature. A P-256 control case (unaffected
  by the bug, same hash on both sides) continues to pass throughout.
• Regression check: P-256 / RSA (sha256 schemes) handshakes unchanged

Related: #377, #399, #161.