If the Finished message is fragmented, the handshake fails with:
javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.

Relevant fragment from the javax.net.debug log:
```
javax.net.ssl|DEBUG|A1|pool-1-thread-1|2025-09-08 21:32:04.069 CEST|ChangeCipherSpec.java:146|Consuming ChangeCipherSpec message
javax.net.ssl|DEBUG|A1|pool-1-thread-1|2025-09-08 21:32:04.070 CEST|SSLCipher.java:1654|Plaintext after DECRYPTION (
  0000: 14 00 00 0C 00 03 00 00 00 00 00 04 BE 89 47 E6 ..............G.
)
javax.net.ssl|ERROR|A1|pool-1-thread-1|2025-09-08 21:32:04.072 CEST|TransportContext.java:368|Fatal (DECRYPT_ERROR): The Finished message cannot be verified. (
"throwable" : {
  javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.
```
In the above log the plaintext contains the first 4 bytes of a 12-byte Finished message. The bytes are processed without waiting for the remaining 8 bytes of the message, and the handshake fails because the bytes don't match the expectations.

It does not usually happen with JSSE peers which pack one message per datagram, but may happen with other implementations that pack multiple messages to the same datagram up to a configured size.

To reproduce easily, use the attached dtls_repro patch to patch the DTLSOverDatagram jtreg test, then run that test.

Disabling stateless session resumption and/or changing the client certificate size may work around the issue.