relay: inbound frames dispatch out of order, so a CLOSE can overtake its REQ #958

Inbound frames are dispatched as independent tasks (crates/nostream-relay/src/relay.rs:304 JoinSet, :498 handlers.spawn(..)), so two frames read in order can run in either order. A REQ followed immediately by CLOSE for the same id can therefore have the CLOSE run first:

1. CLOSE runs: abort_read(id) finds no entry, unsubscribe(id) removes nothing.
2. REQ runs: it registers the subscription and begin_read(id) creates a read that nothing will abort.
3. The read streams to EOSE on a subscription the client closed.

abort_read leaves no tombstone (connection.rs:301-310), so the later begin_read cannot learn that the id was closed.

Why it is not the capture's behaviour

The capture's adapter handles messages in arrival order on one thread: a handler's synchronous prefix — including registering the subscription — has run before the next message is looked at. Rust's JoinSet discards that ordering guarantee. So this is a parity deviation, not a performance choice.

Relationship to #951

#951 restores the abort for a CLOSE processed while the invite mint is in flight, and it does so correctly: begin_read is registered before the mint's only await. But its claim that "a CLOSE is not lost" holds only when the CLOSE is processed after the REQ has registered. Under this defect the CLOSE can be processed first and is lost again, by a different route. #951's build and ADR state that precondition; this issue owns removing it.

A CLOSE for an unknown id is indistinguishable from a CLOSE that overtook its REQ without an ordering token, so a tombstone cannot decide it on its own.

Options, none chosen here

• Run the registration prefix synchronously in the read loop — restores the capture's guarantee for the state that matters, and leaves the awaits (mint, stored read) concurrent as the capture has them.
• Serialize whole handlers — simplest to reason about, but a slow mint would block a subsequent CLOSE, which the capture permits.
• Ordering token per connection — each handler records the arrival sequence and the state machine rejects a CLOSE older than the REQ it would abort; more machinery, exact.

Deciding check

A test that sends REQ then CLOSE back to back with the runtime's task ordering forced (a yield in the REQ handler before it registers), asserting no frame after the CLOSE. At base it streams; after a fix it does not.