Add structured logging with gRPC status codes and correlation IDs in GrpcWorkerChannel

Current gRPC error logging in `GrpcWorkerChannel.cs` lacks sufficient context to diagnose transient communication failures. When investigating ICM 699060688, we could not determine the specific gRPC failure reason.

**Current Gaps:**

| Method | Current Logging | Missing Context |
|--------|----------------|-----------------|
| `HandleWorkerStartStreamError` | Generic exception | gRPC status code, worker state |
| `HandleWorkerInitError` | "Initializing worker process failed" | Timeout duration, expected message type |
| `ProcessInbound` | "Error processing inbound messages" | Message type being processed, correlation ID |
| `SendStreamingMessage` | Silent failure suppression | Failed message type, retry context |

**Proposed Changes:**

1. Add structured logging properties to error handlers:
```csharp
_workerChannelLogger.LogError(exc,
"gRPC worker start failed. WorkerId: {WorkerId}, Runtime: {Runtime}, State: {State}, GrpcStatusCode: {StatusCode}",
_workerId, _runtime, _state, GetGrpcStatusCode(exc));
```

2. Add helper method to extract gRPC status codes from exceptions:
```csharp
private static string GetGrpcStatusCode(Exception ex)
{
if (ex is Grpc.Core.RpcException rpcEx)
return rpcEx.StatusCode.ToString();
return "Unknown";
}
```

3. Log outbound message failures with message type context

Start in GrpcWorkerChannel.cs by reading HandleWorkerStartStreamError, HandleWorkerInitError, ProcessInbound, and SendStreamingMessage. Trace how exceptions, worker state, message types, and correlation IDs are available at each point. Done means the listed failure paths emit the requested gRPC status, worker or message context, retry context, and correlation information without silent loss.

Written by the indexing model from the issue text.