DTLS 1.3: client doesn't acknowledge retransmitted session tickets

While reviewing https://github.com/openssl/openssl/pull/32783, I discovered that a DTLS 1.3 client doesn't send another ACK when a session ticket it has already processed is retransmitted. If the original ACKs are lost, the server keeps retransmitting until it gives up with SSL_R_READ_TIMEOUT_EXPIRED.

I tested this with the code from master at d39b221fd73fd1cce500105c140c33b3dba11d5f, using two OpenSSL peers.

To reproduce:

1. Complete a DTLS 1.3 handshake with the server's default two session tickets enabled.
2. Let the client process both tickets, but drop the ACK datagrams it sends back.
3. Deliver all subsequent traffic normally, including the server's retransmissions.
4. Continue reading on both peers and service the server's timer with DTLSv1_handle_timeout() until it reaches the retry limit.

In my test, I advanced the server timeout deadline before each call to DTLSv1_handle_timeout to keep the run short. Every retransmission was delivered, but the client never sent another ACK. The server failed on the thirteenth timeout, and subsequent application writes failed too.

The retransmitted records have fresh record numbers but keep the original handshake message sequence numbers. In dtls1_process_out_of_seq_message, they enter the code that discards older messages. That code consumes them without adding their record numbers to the ACK list or arranging another ACK.

I would expect the client to acknowledge these retransmissions without processing the tickets again. RFC 9147 §7 recommends sending ACKs for records received after the handshake, including messages discarded because an earlier copy was already received. Losing the original ACKs shouldn't prevent recovery once later traffic gets through.