…wn (#13450)

## Summary

Fix a race condition crash (access violation 0xC0000005 /
NullReferenceException) in `LoggingService.ProcessLoggingEvent` when the
method is called after the logging service has been shut down.

## Problem

`ProcessLoggingEvent` directly accesses `_eventQueue`, `_dequeueEvent`,
and `_enqueueEvent` without any shutdown guard. During
`ShutdownComponent()`, `CleanLoggingEventProcessing()` disposes and
nullifies all of these fields. If an external callback (e.g.,
`Process.Exited` from a `ProjectCachePlugin`) attempts to log a message
after shutdown has completed, the null field access causes an
unrecoverable crash.

### Reproduction Scenario

1. A build runs with a `ProjectCachePlugin`
2. The build completes and `LoggingService.ShutdownComponent()` is
called
3. The cache plugin's external process exits, triggering
`Process.OnExited` on a ThreadPool thread
4. The callback logs "Project cache service process exited" via
`LoggingServiceToPluginLoggerAdapter.LogMessage`
5. This calls `ProcessLoggingEvent()` which accesses `_eventQueue.Count`
→ **null reference crash**

### Debugger Evidence

```
_serviceState = Shutdown
_eventQueue = null
_dequeueEvent = null
_enqueueEvent = null
_emptyQueueEvent = null
_loggingEventProcessingCancellation = null

buildEvent.Message = "Project cache service process exited"
Call: System.Diagnostics.Process.OnExited -> ProjectCachePlugin.dll -> LoggingServiceToPluginLoggerAdapter.LogMessage
```

## Root Cause

`ProcessLoggingEvent` lacked two protections that already exist
elsewhere in the codebase:

1. **Shutdown state guard** - Other public methods (`RegisterLogger`,
`RegisterDistributedLogger`, `InitializeNodeLoggers`,
`InitializeComponent`) all check `_serviceState !=
LoggingServiceState.Shutdown`. `ProcessLoggingEvent` did not.

2. **Local field capture** - The `LoggingEventProc` queue pump thread
already captures `_eventQueue`, `_dequeueEvent`, `_emptyQueueEvent`, and
`_enqueueEvent` into local variables to prevent races with
`CleanLoggingEventProcessing()`. `ProcessLoggingEvent` accessed the
fields directly.

## Fix

Three layers of defense, all following patterns already established in
the same file:

1. **Early return** when `_serviceState == LoggingServiceState.Shutdown`
- silently drops the event, since the service is no longer operational.
2. **Capture fields to locals** before use - prevents null dereference
if `CleanLoggingEventProcessing()` runs concurrently between the state
check and the field reads.
3. **Null-check the captured locals** - second defense against the
TOCTOU race between step 1 and step 2.

## Risk

**Low.** The fix only adds early-exit guards - no behavioral change for
the normal (non-shutdown) code path. The patterns used are already
established in the same file.

…wn (dotnet#13450)

## Summary

Fix a race condition crash (access violation 0xC0000005 /
NullReferenceException) in `LoggingService.ProcessLoggingEvent` when the
method is called after the logging service has been shut down.

## Problem

`ProcessLoggingEvent` directly accesses `_eventQueue`, `_dequeueEvent`,
and `_enqueueEvent` without any shutdown guard. During
`ShutdownComponent()`, `CleanLoggingEventProcessing()` disposes and
nullifies all of these fields. If an external callback (e.g.,
`Process.Exited` from a `ProjectCachePlugin`) attempts to log a message
after shutdown has completed, the null field access causes an
unrecoverable crash.

### Reproduction Scenario

1. A build runs with a `ProjectCachePlugin`
2. The build completes and `LoggingService.ShutdownComponent()` is
called
3. The cache plugin's external process exits, triggering
`Process.OnExited` on a ThreadPool thread
4. The callback logs "Project cache service process exited" via
`LoggingServiceToPluginLoggerAdapter.LogMessage`
5. This calls `ProcessLoggingEvent()` which accesses `_eventQueue.Count`
→ **null reference crash**

### Debugger Evidence

```
_serviceState = Shutdown
_eventQueue = null
_dequeueEvent = null
_enqueueEvent = null
_emptyQueueEvent = null
_loggingEventProcessingCancellation = null

buildEvent.Message = "Project cache service process exited"
Call: System.Diagnostics.Process.OnExited -> ProjectCachePlugin.dll -> LoggingServiceToPluginLoggerAdapter.LogMessage
```

## Root Cause

`ProcessLoggingEvent` lacked two protections that already exist
elsewhere in the codebase:

1. **Shutdown state guard** - Other public methods (`RegisterLogger`,
`RegisterDistributedLogger`, `InitializeNodeLoggers`,
`InitializeComponent`) all check `_serviceState !=
LoggingServiceState.Shutdown`. `ProcessLoggingEvent` did not.

2. **Local field capture** - The `LoggingEventProc` queue pump thread
already captures `_eventQueue`, `_dequeueEvent`, `_emptyQueueEvent`, and
`_enqueueEvent` into local variables to prevent races with
`CleanLoggingEventProcessing()`. `ProcessLoggingEvent` accessed the
fields directly.

## Fix

Three layers of defense, all following patterns already established in
the same file:

1. **Early return** when `_serviceState == LoggingServiceState.Shutdown`
- silently drops the event, since the service is no longer operational.
2. **Capture fields to locals** before use - prevents null dereference
if `CleanLoggingEventProcessing()` runs concurrently between the state
check and the field reads.
3. **Null-check the captured locals** - second defense against the
TOCTOU race between step 1 and step 2.

## Risk

**Low.** The fix only adds early-exit guards - no behavioral change for
the normal (non-shutdown) code path. The patterns used are already
established in the same file.