Fix unhandled ObjectDisposedException in TimestampedFileLogger during workload repair

[Copilot]

After dotnet workload repair completes on Windows, an unhandled ObjectDisposedException crashes the process because BlockingCollection<T>.IsAddingCompleted itself throws when the collection is already disposed — and that check sat outside the try-catch in WriteMessage.

The race: Shutdown() disposes the logger, then the elevated server process exit fires Process.Exited asynchronously on a threadpool thread (InstallClientElevationContext.ServerExited → LogMessage → WriteMessage), hitting the disposed BlockingCollection.

Change

• TimestampedFileLogger.WriteMessage: expand the try-catch to also cover the IsAddingCompleted property access, not just Add().

// Before — IsAddingCompleted outside try, throws ObjectDisposedException unhandled
if (!_messageQueue.IsAddingCompleted)
{
    try { _messageQueue.Add(message); }
    catch (ObjectDisposedException) { }
    catch (InvalidOperationException) { }
}

// After — entire guard + add is protected
try
{
    if (!_messageQueue.IsAddingCompleted)
        _messageQueue.Add(message);
}
catch (ObjectDisposedException) { }
catch (InvalidOperationException) { }

[Copilot]

Pull request overview

Fixes a shutdown race in the Windows workload repair logging path where TimestampedFileLogger.WriteMessage could throw an unhandled ObjectDisposedException after the logger was disposed.

Changes:

• Wrapes the BlockingCollection.IsAddingCompleted check in the existing exception handling so disposal races no longer crash the process.

[Copilot]

Consider adding a regression test that calls LogMessage after TimestampedFileLogger.Dispose() (or races Dispose() with a thread calling LogMessage) to ensure the ObjectDisposedException/InvalidOperationException paths here remain non-fatal. This scenario is easy to exercise in WindowsInstallerTests, and it would prevent this shutdown race from reappearing.