gRPC broadcast stream never closed in OrdererClient.send() causing connection leak

## Bug Description

**Component:** `tools/fxconfig/internal/client/orderer.go:74–101`
**Type:** Resource Leak

### Summary

The `send()` method in `OrdererClient` opens a gRPC broadcast stream via `client.Broadcast(ctx)` but **never calls `CloseSend()`** on the stream. When `Send()`,`Recv()`, or the status check fails, the stream is abandoned without proper cleanup, causing a connection leak. Even on the success path, the stream is not closed before returning.

### Steps to Reproduce

1. Create an `OrdererClient` instance with a valid connection .
2. Call `send()` with a transaction envelope.
3. Trigger an error condition (e.g., orderer rejects, network glitch, timeout) .
4. Observe: the gRPC stream remains open; `CloseSend()` is never invoked .

### Expected Behavior

The broadcast stream must be closed via `CloseSend()` after use to:
- Signal the server that the client is done sending.
- Allow proper server-side stream termination.
- Release the underlying connection immediately instead of waiting for context cancellation.

### Actual Behavior

The stream is leaked because `abc.CloseSend()` is never called:
- On `Send()` error: stream abandoned, connection leaked.
- On `Recv()` error: stream abandoned, connection leaked.
- On `Status_SUCCESS` check failure: stream abandoned, connection leaked.
- On success: stream abandoned, connection leaked.

### Root Cause

Missing `defer abc.CloseSend()` call immediately after successfully opening the stream.

### Suggested Fix

```go
abc, err := oc.client.Broadcast(ctx)
if err != nil {
return err
}
defer abc.CloseSend() // ← Add this line to ensure cleanup on all paths

err = abc.Send(env)
// ...
```
Impact

- Connection exhaustion under sustained load.
- File descriptor leaks accumulating over time.
- Potential orderer service degradation as available connections are exhausted.
- Harder debugging because leaked streams may mask the true root cause of failures.