drpcmanager: add soft cancel grace period

[mniewrzal]

Problem

Options.SoftCancel exists so that canceling a stream does not cost the whole transport: the manager sends a KindCancel packet and keeps the connection for the next stream.

That only works if the cancel can actually be sent. Stream.SendCancel needs the stream's state and write mutexes and takes both with TryLock — deliberately, so that a wedged transport write can never block teardown. The consequence is that a stream which happens to be sending when the cancel arrives reports busy, and the manager hard cancels: transport destroyed, next call pays a dial and a handshake.

For clients whose streams send and receive concurrently, that race is both common and benign. Losing the connection over it is a poor trade.

Change

• Options.SoftCancelGrace bounds how long a busy soft cancel will wait for the concurrent send to finish. Zero or negative preserves today's behavior.
• Manager.sendCancel implements the wait by retrying SendCancel with backoff (100µs, doubling to a 5ms cap) rather than blocking on the mutex. Blocking would give back exactly the property that lets a dead transport be torn down; polling keeps it. The loop also exits early if the manager terminates, since there is nothing left to preserve at that point.
• The outcome of each soft cancel attempt — CancelClean, CancelBusy or CancelError — is reported through a callback in the internal options, following the existing statsCB pattern. The ratio of kept to destroyed transports is the difference between a connection pool that works and one that never gets a hit, and it is not otherwise observable in production.

Tests

TestSoftCancel_Grace parks a flush inside the transport, waits until the write is actually blocked, cancels the stream's context, and releases the write 50ms later. With no grace the manager reports busy; with a grace period the retry picks the stream up once the send lands and the cancel is delivered cleanly.