TLS 1.3 KeyUpdate handling can race concurrent writes

Summary

Reseau 1.1.0 through 1.3.1 process a peer-requested TLS 1.3 `KeyUpdate(update_requested)` response from the read path without acquiring the connection's write lock. A connected peer can race that response against an application task writing on the same connection.

### Impact

The two tasks can concurrently use and replace shared write-cipher state, including the record sequence number, nonce and output buffers, key material, and OpenSSL AEAD context. Depending on timing, this can cause AEAD nonce reuse, corrupted or disclosed plaintext, use-after-free behavior in OpenSSL, or process termination.

The attack requires TLS 1.3, concurrent reader and writer tasks, and winning a race with an otherwise valid post-handshake KeyUpdate message.

### Technical details

Application writes hold `conn.write_lock`, but the vulnerable KeyUpdate handler wrote its response and called `_tls13_advance_write_cipher!` while holding only the read lock. The application writer and handler could therefore encrypt with the same sequence number, resize a shared output buffer while another task held its pointer across an I/O yield, or free and replace an EVP context still in use by the writer.

The vulnerable native TLS implementation first shipped in Reseau 1.1.0. Releases 1.0.x used the previous OpenSSL TLS engine and are not affected.

### Patches

Upgrade to Reseau 1.3.2 or later. The fix serializes both the KeyUpdate response and write-cipher rotation under the same write lock used by application writes.

### Workarounds

Configuring connections to use TLS 1.2, or ensuring that no application writer runs concurrently with the connection reader, avoids this particular race. Upgrading is recommended because those restrictions can be difficult to enforce for full-duplex protocols.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.