fix(runtime): drain shared-memory final close deterministically

[SunSi12138]

Part of #387.

SharedMemoryControlChannel.DisposeAsync previously started its 250 ms writer fallback immediately after queueing the final Close signal. On a heavily scheduled CI worker, that budget could expire before the writer continuation ever ran, allowing stream disposal to race ahead of the final control signal.

The first version of this PR tried to distinguish scheduler delay from a genuinely blocked write by separately observing _writerActive == 0 and _pendingOutboundSignals == 0 before queueing Close. That observation was itself racy: another thread could queue a Data/Space signal and let the writer enter a blocking write between the idle/empty check and Close enqueue, causing Dispose to wait indefinitely for Close to start and bypass the 250 ms fallback.

The updated fix makes that ownership decision atomic. Writer active state, pending-signal enqueue/dequeue, and Dispose's idle + empty -> queue Close transition are serialized by one outbound-state gate. Disposal only waits without a timeout for Close to begin when it atomically proves there is no preceding queued or active write; if any work already exists, it keeps the original bounded 250 ms cleanup path.

This preserves the purpose of the fix—do not charge pure writer scheduling delay against the 250 ms blocked-write budget—without allowing a concurrent signal to create an unbounded wait behind an earlier write.

Regression tracked by SharedMemoryControlChannelTests.DisposeShouldDrainTheFinalCloseSignalBeforeCompletingWakeSource.

Supersedes draft #411, which was closed only because the connector's Ready-for-review transition currently errors on an unsupported GraphQL field.