SHM transport teardown may leave dangling SelfRef borrows into unmapped memory

[fasterthanlime]

Problem

When the shared memory transport is torn down (region unmapped), there may still be outstanding SelfRef backing that borrows from the shared memory region. If any code still holds a SelfRef pointing into the unmapped region, accessing it is use-after-unmap — unsoundness.

How it could happen

1. A response arrives over the SHM transport
2. The response payload is deserialized as a SelfRef<T> borrowing from the SHM ring buffer
3. The SHM transport is torn down (e.g., session resumption on a new conduit, or peer crash)
4. The shared memory region is unmapped
5. Code still holding the SelfRef accesses the data — dangling pointer

What needs investigation

• Can SelfRef outlive the SHM region in practice? What are the ownership/lifetime guarantees?
• Does the ring buffer slot stay pinned while a SelfRef references it?
• If not, what prevents the slot from being recycled while a borrow is outstanding?

Discovered while working on the retry spec (#231) — session resumption on a new conduit implies the old transport can be torn down while responses from it are still in use.