Test: cover the restart race that monitor-routed values close

[dbrattli]

Split out of the review of #25.

#25 rewrote flatMapActorSupervised so upstream values route through the monitor instead of a shared ref + TaskCompletionSource handshake. The stated win is that upstream can no longer post to a stale child mid-restart, because a message cannot be dequeued until the loop is running and the loop only starts after the child is spawned.

No test exercises that. The nearest one, flatMapActorSupervised Restart accepts future items after crash, deliberately avoids the race:

do! obv.OnNextAsync 2
// Wait for crash + restart before sending item 3
do! Async.Sleep 200
do! obv.OnNextAsync 3

It passes against both the old and new implementations.

What to add

A test that fires items back-to-back through a crash, with no spacing — items queued behind the crashing one must reach the restarted child rather than the dead one:

// handler crashes on 2; 3, 4, 5 are already queued when the crash happens
let xs = fromNotification [ OnNext 1; OnNext 2; OnNext 3; OnNext 4; OnNext 5; OnCompleted ]
// expect [10; 30; 40; 50] — only the crashing item is lost

This should fail against the pre-#25 childRef version and pass now.

Also worth covering: ordering is preserved across the extra monitor hop (values arrive in upstream order, not just as a set).

Both are .NET-target tests; they will also serve as BEAM regression coverage once terminal-notification propagation is fixed there.