chore(quest): finish the lifetimes quest

quest/m1/ffi-export/README.md

@@ -60,5 +60,4 @@ than `ctypes`; the others call C natively. moq's packages switch to them in moq'
 - [Dart: calls into a held implementation while the isolate waits](/quest/m1/ffi-export/dart-threads.md) - an implementation Rust kept and calls from another thread runs, or fails loud, while the isolate waits in a call
 - [Dart: cheaper ready futures](/quest/m1/ffi-export/dart-futures.md) - a read ready at its first poll costs no more than in Python or Go
 - [Go: cheaper lent Bytes](/quest/m1/ffi-export/go-bytes.md) - a lent buffer costs no more than a 1 KiB copy, so Go's 2 KiB copy threshold can fall or go
-- [Lifetimes with no undefined behavior](/quest/m1/ffi-export/lifetimes.md) - errors after `close()` in Kotlin and Go, lends that never end under a call, GC-owned bytes, and C++ smart pointers
 - [Kotlin: lent bytes freed before native memory piles up](/quest/m1/ffi-export/kotlin-native-memory.md) - reading many large `Bytes` holds a bounded backlog of Rust's memory even when the GC rarely runs

quest/m1/ffi-export/kotlin-native-memory.md

@@ -10,7 +10,7 @@ growing native heap behind it.
 ## Plan
 
 Found by [#432](https://github.com/moq-dev/rust2/pull/432), which made bytes over 1 KiB
-GC-owned under [the lifetimes quest](/quest/m1/ffi-export/lifetimes.md): Rust's buffer is
+GC-owned: Rust's buffer is
 freed by a cleaner once the GC collects its `Native.Lent`, and the JVM does not see the
 buffer's size. A scratch loop returning a fresh Rust buffer per call measured 1.6 to 13 µs
 per lent `Bytes` from 1025 B to 16 KiB, against 0.15 to 3.4 µs with every size copied, as
@@ -28,7 +28,3 @@ the numbers support. Options to weigh:
 
 No `close()` comes back: a free while a slice is live is what the lifetimes quest removed.
 Go's `Bytes` has the same shape (`runtime.AddCleanup`); note whether its fix applies there.
-
-## Required
-
-- [Lifetimes with no undefined behavior](/quest/m1/ffi-export/lifetimes.md) - #432's GC-owned Kotlin bytes land first

quest/m3/ffi-cpp-shared-future.md

@@ -12,14 +12,9 @@ Found by [#430](https://github.com/moq-dev/rust2/pull/430), whose design this fi
 types passing its clone guard hold their handle through `std::shared_ptr`, and a move
 out of a copy that others share moves out a clone instead. A pending future borrows
 Rust's handle without holding a `shared_ptr`, so `use_count` reads 1 and the move takes
-the borrowed value, which Rust refuses. Starts once #430 merges, and changes with it if
-the maintainer settles its `Arc` decision another way.
+the borrowed value, which Rust refuses.
 
 Options to weigh: a future holds a `shared_ptr` copy of the handle it borrows, so
 `use_count` sees it; or the move asks Rust whether the handle is borrowed and clones if so.
 Prove it with a test that destroys the copy a pending future came from, then moves out
 of the last copy.
-
-## Required
-
-- [Lifetimes with no undefined behavior](/quest/m1/ffi-export/lifetimes.md) - #430's shared C++ handles land first