Fix null-forgiving operator misuse in System.Diagnostics.EventLog

[Copilot]

Description

Follow-up to #119891 (NRT annotations for System.Diagnostics.EventLog). Addresses unresolved review comments by replacing unsafe null-forgiving operator (!) usage with proper null checks where the nullable type is genuine.

• EventLogTraceListener: EventLog property is EventLog? but all TraceEvent/TraceData methods used EventLog!.WriteEvent(...). Replaced with local capture + early return on null (6 sites).
• EventLogInternal parent!: parent field is EventLog? and genuinely null in static write paths and listener infrastructure. Replaced parent!.ComponentDesignMode with parent?.ComponentDesignMode == true (4 sites).
• CompletionCallback TOCTOU: onEntryWrittenHandler field was null-checked then accessed via this.onEntryWrittenHandler — racy if unsubscribed between check and invocation. Captured to local.
• InternalWriteEvent: strings[i]!.Length after strings[i] ??= string.Empty — replaced with string s = strings[i] ??= string.Empty; if (s.Length > ...) to eliminate the suppression.

Suggested further improvements (separate PRs)

1. IEnumerable<string?> inner nullability in Reader APIs may be overly broad — EvtVarTypeNull may be the only null variant
2. EventRecord.FormatDescription(IEnumerable<object>? values) accepts null but a parameterless overload exists
3. EventRecordWrittenEventArgs constructors could unify null handling
4. LogListeningInfo fields could be readonly
5. ref/impl nullable annotation mismatches need API review process

[krwq]

cc: @RenderMichael - note this PR is auto-generated

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/area-system-diagnostics-tracing
See info in area-owners.md if you want to be subscribed.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🔵 Needs a closer look

One or more issues must be addressed before approval.

Pull request overview

This PR removes unsafe null-forgiving usage in System.Diagnostics.EventLog and adds null-listener coverage.

Changes:

• Adds null-safe EventLogTraceListener behavior.
• Makes EventLogInternal parent and callback handling null/race-safe.
• Removes remaining null-forgiving operators in write paths.

File summaries

File	Description
src/libraries/System.Diagnostics.EventLog/tests/EventLogTraceListenerTests.cs	Updated as part of this pull request.
src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/EventLogTraceListener.cs	Updated as part of this pull request.
src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/EventLogInternal.cs	Updated as part of this pull request.
src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/EventLog.cs	Updated as part of this pull request.

Review details

Suppressed comments (1)

src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/EventLogInternal.cs:566

• This change fixes a callback TOCTOU race, but the added tests do not exercise it: the existing event tests never configure SynchronizingObject or unsubscribe the handler between the null check and invocation. Please add a deterministic regression test (for example, an ISynchronizeInvoke test double whose InvokeRequired removes the subscription) so the old this.onEntryWrittenHandler access would fail and this local capture is verified.

[!NOTE] This review comment was created by GitHub Copilot.

                        EntryWrittenEventHandler? handler = onEntryWrittenHandler;
                        if (handler is not null)
                        {
                            ISynchronizeInvoke? synchronizingObject = SynchronizingObject;
                            if (synchronizingObject is not null && synchronizingObject.InvokeRequired)

• Files reviewed: 4/4 changed files
• Comments generated: 0
• Review effort level: Lite