v0.48.1

This release fixes a class of bugs where a value the server couldn't serialize ended the connection instead of being reported as an error (#55, #65).

The reported bug. On the pipe transport, a unary method returning a value that doesn't fit its declared type (-> int returning a str) answered the client with a bare StopIteration and stopped the server, so the next call on that connection hung. The failure is now a typed RpcError and the connection keeps serving. HTTP was not affected.

The same bug elsewhere. Every case below now raises a typed RpcError on the call that caused it, the connection keeps serving, and the access log records the call as error:

• Stream header: a header that doesn't fit its type, or header=None when a header is declared. Affected pipe and HTTP producer streams.
• Not a stream: a stream method returning no Stream, or a Stream whose output_schema isn't a pa.Schema. Affected pipe and HTTP.
• call_state: a value that can't be serialized. Affected HTTP.
• ctx.client_log: a non-JSON extra during stream init. Affected pipe and HTTP producer streams.
• ExternalRef: a URL that can't be encoded. Affected pipe.
• Exceptions: an exception whose __str__ raises. Affected all transports.
• Cookies: ctx.set_cookie / ctx.delete_cookie with an invalid name or same_site now raise ValueError when called. Previously this was an unhandled HTTP 500 after the method had already run.

Client:

• A response stream that carries no batch raises RpcError("ProtocolError") instead of leaking StopIteration.
• A non-Arrow error body (e.g. a proxy's HTML 502) on a header-declaring HTTP stream init raises HttpError instead of a raw ArrowInvalid.

No wire-format change.