drpcstream,drpcmanager: enable per-stream flow control (grant-on-consume)

[suj-krishnan]

Installs per-stream flow-control windows from an internal FlowControl option and proves the mechanism end to end. This is the enablement layer only; the message-boundary overdraft that makes it deadlock-free for multi-frame and larger-than-window messages is stacked on top in #92.

Installs the per-stream windows when FlowControl is set: the send window seeded with StreamWindow credit and watching the send signal for termination; the receive window returning consumed-byte credit coalesced at GrantThreshold.

Enablement is internal-only (merge safety). The option lives in internal/drpcopts (SetStreamFlowControl), not on the public drpcstream.Options — so a consumer bumping the drpc dependency mid-implementation cannot enable flow control: no public API reaches it. Promotion to a public option is a later, deliberate change.

Validation at the installation site. An invalid configuration resorts to mutually-consistent defaults (and logs the override) instead of failing the stream:

• StreamWindow and GrantThreshold must be positive;
• a non-positive SplitSize uses SplitData's 64 KiB default as the frame size;
• GrantThreshold + frame ≤ StreamWindow — the liveness guarantee for grant coalescing. With G = GrantThreshold, W = StreamWindow, F = frame: once the receive side has consumed more than W − F of the window, the sender has < F credit left and halts; if G > W − F, the receiver cannot emit a grant to unblock it either — deadlock. Requiring G ≤ W − F prevents that.

End to end. drpcmanager tests move more data than the window holds over a real net.Pipe, so the transfer only completes if consume-driven grants flow back across the connection; context cancellation wakes a sender parked on credit through the production manageStream path; and a default-configuration (flow-control-off) connection never puts a KindWindowUpdate on the wire.