IoPool: a leaf between Subscribe() and its ThreadPool prologue is invisible to Drain()'s grace #4555

The window

Between a caller's Subscribe() returning and the ThreadPool running the leaf's prologue, the leaf
is counted by nothing — not _gateUsers, not _inFlight, not CurrentlyWaiting. The caller
believes the work is queued; the pool does not know it exists.

Three of the four entry points have such a window, and the consequence is not the same in each:

// Invoke / InvokeStream — the admission is inside the scheduled body
=> Observable.FromAsync(async subscriberCt =>
   {
       if (!TryEnterGateRegion())          // ← on a POOL thread
           throw new OperationCanceledException(DisposedMessage);
       ...
   }).SubscribeOn(TaskPoolScheduler.Default);

// SubscribeThroughPoolCore — outer region taken synchronously, but released before the setup leaf runs
try { ... var setup = Observable.FromAsync(...).SubscribeOn(TaskPoolScheduler.Default).Subscribe(...); ... }
finally { LeaveGateRegion(); }             // ← released at the end of the synchronous subscribe

Why it matters to Drain()

Drain()'s grace waits while anything is outstanding and restarts on every completion. If the
outstanding count reaches zero inside this window, the grace ends and the pool token is
cancelled. For Invoke/InvokeStream the invisible leaf is then cancelled at its gate wait — too
late to appear in LeavesCancelledAfterGrace / CancelledLeafSites, which are captured before the
cancel. That is accepted work discarded without being named, the same contract violation #3291
addressed from the other direction (teardown lets accepted work finish and names what it had to
stop).

What is measured and what is not

• Structural / readable from the code: the window itself, and which entry points have it.
• NOT measured: that it has ever fired. I did not reproduce a leaf being silently cancelled
  through it, and I am not claiming it caused the failure in Drain() can cancel pooled leaves that were accepted but still QUEUED for a slot — IoPoolTest grace-restart test failed 1 of 5 under CPU saturation #4541.

#4541 was a different defect in the same method — the grace read progress off the live admission
census, so an arrival cancelled out a completion and the per-completion grace collapsed into one
total budget. That one is reproduced deterministically and fixed in #4556. Fixing it does not
close this window; it only removes the masking. Both mechanisms produce the same observable symptom
(a queued leaf cancelled during a drain), which is why they are worth keeping apart.

The likely shape of a fix

Take the admission on the subscriber's thread, the way InvokeBlocking already does, and hold it
until the leaf terminates — a small Observable.Create wrapper that enters the region, subscribes
the SubscribeOn'd leaf, and leaves the region exactly once on terminal-or-dispose. Then "accepted"
means the same thing on every entry point, and a leaf whose Subscribe() returned before the drain
finished its grace is either run to completion or named as cancelled.

Two things to weigh, neither blocking:

1. It moves the refusal terminal (OperationCanceledException for a disposed/draining pool) onto
   the subscriber's thread. That matches what the build-time refusal already does — Cancelled<T>()
   is Observable.Throw on the immediate scheduler — but it is adjacent to IoPool: a late drain registration no longer runs a pooled teardown on the subscriber's thread (#4524) #4533 / A pooled leg REFUSED after Drain()/Dispose() terminates inside Subscribe() on the subscriber's thread — OrderedRouteDispatcher.DrainNext then recurses through its queue #4530, which are
   about which thread a terminal runs on, so it should land with those in view rather than against
   them.
2. It touches the hottest entry points in the system, so it wants its own PR and its own review
   rather than riding along with a drain fix.

Deliberately filed rather than fixed in #4556: that PR is scoped to Drain() and its counters, and
the subscribe path is being edited concurrently (#4530 / #4545).

Refs #4541, #3291, #4524, #4533, #4530, #4545, #4556.