Fix MSBuild telemetry when the server is enabled

[baronfel]

Fixes #55578

Summary

• initialize and reuse the telemetry client when MSBuildLogger runs in the persistent MSBuild server
• create an internal MSBuild activity at BuildStarted, set its result at BuildFinished, and drain pending telemetry during logger shutdown
• forward W3C trace context from the invoking CLI and resolve it for every server build so MSBuild spans remain nested under the correct command invocation
• flush completed disk-log activities after successful writes so consecutive server builds do not duplicate prior spans
• cover activity ownership, trace propagation, and consecutive builds through one persistent MSBuild server

Testing

• focused TelemetryClientTests, GivenMSBuildLogger, and propagation suite (24 tests)
• managed CLI and Native AOT shared-source builds
• two builds through one persistent server using the local 11.0.100-dev redist SDK and Aspire Dashboard; each trace contained a nested internal msbuild span with Ok status and the expected MSBuild telemetry events

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
2 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]

Pull request overview

This PR addresses missing msbuild/* telemetry when the MSBuild server is enabled by ensuring the CLI telemetry pipeline is correctly initialized and that MSBuild events run under an internal Activity within the persistent server process.

Changes:

• Initialize/reuse TelemetryClient from MSBuildLogger and create an internal MSBuild Activity spanning each build.
• Improve disk-log flushing behavior to avoid duplicating previously-written spans across consecutive server builds.
• Add tests covering MSBuild-server telemetry persistence and per-build activity ownership.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
test/dotnet.Tests/TelemetryTests/TelemetryClientTests.cs	Adds an integration-style test that runs two consecutive builds with MSBuild server enabled and asserts telemetry is captured.
test/dotnet.Tests/CommandTests/MSBuild/GivenMSBuildLogger.cs	Adds a unit test asserting MSBuildLogger creates an internal activity per build and restores the parent activity afterward.
src/Cli/dotnet/Telemetry/TelemetryDiskLogger.cs	Changes WriteLog to return success/failure so callers can conditionally drain in-memory activities after a successful write.
src/Cli/dotnet/Telemetry/TelemetryClient.cs	Tracks initialization state and drains written activities from the in-memory exporter after successful disk writes; adds a hook to wait for pending TrackEvent tasks.
src/Cli/dotnet/Commands/MSBuild/MSBuildLogger.cs	Initializes telemetry in the MSBuild server process, creates/stops an internal build activity, and drains pending telemetry + disk-log flushing on shutdown.

Suppressed comments (1)

src/Cli/dotnet/Commands/MSBuild/MSBuildLogger.cs:290

• Shutdown stops the current activity before waiting for pending telemetry tasks. If any TrackEvent tasks are still queued, stopping first risks losing events for exporters that snapshot at Activity.Stop(). Waiting before stopping is safer.

    public void Shutdown()
    {
        StopActivity();

        if (_telemetry is TelemetryClient telemetryClient)

[dotnet-policy-service]

This PR has been labeled with Area-Telemetry. Please ensure that any telemetry changes in this PR

• comply with the published guidance * are added to the repo-local telemetry documentation * get a matching .NET Docs issue raised to document the telemetry changes
  • Go to https://learn.microsoft.com/dotnet/core/tools/telemetry
  • Scroll down to the bottom and click the 'Open a documentation issue' link to create an issue with pre-filled details

[baronfel]

This PR restores delivery and correlation for the existing documented msbuild/* events; it does not add any event, property, or data point. Commit 8d93dae adds a hosting/lifecycle clarification to documentation/project-docs/telemetry.md. Because the public telemetry inventory is unchanged, no matching .NET Docs issue is needed.