After walking through our handling of streamable client context
cancellation (due to encountering a shutdown deadlock), I think I've
settled on a more coherent strategy for handling call cancellation:

- In our call handler, retire the request if the call exits due to
  cancellation: the caller will never see the actual result anyway.
- In connectSSE, use the actual request context (the same context used
  in Write) for the client request, so that it terminates when the
  context is cancelled. Thread through the initialization context for
  the standalone SSE request.

Also, a couple minor improvements:
- Use a detached context for the background context of the client
  connection. We want to preserve context values (see modelcontextprotocol#513), but it is
  not right to cancel the connection after Connect has already returned,
  if the context times out.
- Don't use Last-Event-ID != "" as the signal for whether the connectSSE
  call is initial: if the standalone SSE stream disconnects without an
  event ID, we'll still reconnect it, and don't want to do so without a
  delay.

+ tests, updating the streamable client connection test harness to
  accomodate the new aspects being exercised.

Fixes modelcontextprotocol#662