drpcstream: gate data-frame sends on the per-stream send window

[suj-krishnan]

Two commits:

1. drpcstream: take the write lock without holding s.mu — a standalone locking change: Close/SendError/CloseSend release s.mu, wait for s.write, then re-lock and re-check state. Holding s.mu while waiting deadlocks every path that needs it (Cancel, terminate, the connection reader) behind a slow writer, and a mixed order is an ABBA deadlock. Uniform rule: s.write before s.mu; never wait on s.write holding s.mu. Regression test uses transport backpressure (no flow control involved).

2. drpcstream: gate data-frame sends on the per-stream send window — wires the sendWindow credit gate into the stream write path:

• In rawWriteLocked, a KindMessage frame acquires len(frame) bytes of per-stream send credit before it is handed to the writer.
• Control kinds (invoke/metadata/etc.) bypass the gate — flow control applies to data frames only.
• terminate closes the window with the send-side error (sigs.send.Err() — first-wins, so io.EOF when a cancel/error path pre-set it): a send parked on credit returns the same error as one parked in MuxWriter.WriteFrame or a later send. SendError's pre-close uses io.EOF and Close's uses termClosed for the same parked/unparked agreement.
• Close and SendError close the send window before touching the write lock (signal-first, like SendCancel), so a credit-parked send wakes and releases the lock instead of stalling them on a grant that may never come.

Preemption matrix for the four callers that take the write lock:

Caller	Terminates?	Behind a parked send
SendCancel	yes	preempts (already signal-first)
Close	yes	preempts (fixed here)
SendError	yes	preempts (fixed here)
CloseSend	no — half-close	waits (write-then-mu order); parked send completes on grant, and termination can always break the wait

---

Commit 3 — drop the redundant lock on the fast-path termination check

The first termination check in Close, SendError, and CloseSend held s.mu around what is only an atomic signal read. drpcsignal.Signal is internally synchronized (an atomic status word, with an internal mutex only on the slow paths of Set/Signal), so IsSet() is race-free without s.mu. That first check is a best-effort fast path; the authoritative guard against a concurrent termination is the re-check under s.mu after the write lock is acquired — which is unchanged. So the lock on the fast path does no correctness work, and the check now reads the signals locklessly.

For Close and SendError, the early sendw.close() also moves out of that lock: sendWindow is self-synchronized and idempotent (first-writer-wins), so it needs no s.mu either.

No behavior change: the signals are monotonic (set-once), so a race on the fast path at worst does a little extra work before the authoritative re-check returns. s.mu is still held, as before, across every check that gates a state transition — those compound read-then-mutate sequences (e.g. terminateIfBothClosed, terminate, checkFinished) are what the mutex actually protects, not the individual signal reads.

[shubhamdhama]

These are the comments for the first commit.

[shubhamdhama]

This comment is related to the other PR.

[shubhamdhama]

This doesn't need to be wrapped in s.mu locks. Both are concurrency safe.

[shubhamdhama]

Same here: This doesn't need to be wrapped in s.mu locks. Both are concurrency safe.

[shubhamdhama]

This one too: This doesn't need to be wrapped in s.mu locks. This is concurrency safe.

[shubhamdhama]

Also from a correctness point of view this isn't required, but we can keep it as a "fast-path". So not asking for any change here.

[shubhamdhama]

s.Context() is useless here. close does the trick of aborting. I would recommend just keep the n and remove the context.

[Nukitt]

Close, SendError, and CloseSend now all have nearly identical lock unlocks, maybe we should add in a small helper that could reduce the duplication?