Document Process timing properties after exit

[Copilot]

Process timing information remains available after exit on Windows, while Unix discards uncached information when reaping the process.

Changes

• Add cross-platform coverage for StartTime, ExitTime, and processor-time properties after immediate process exit.
• Verify unavailable Unix timing properties consistently throw InvalidOperationException.
• Document Windows handle retention and Unix StartTime caching behavior in XML documentation.

fixes #125741

[azure-pipelines]

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

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR adds test coverage and XML documentation clarifying how System.Diagnostics.Process timing properties behave after a process exits, highlighting cross-platform differences (Windows retains timing data via process handles; Unix may lose uncached timing data after reaping).

Changes:

• Adds a new cross-platform test validating StartTime, ExitTime, and processor-time properties after an immediate process exit.
• Updates XML docs to describe post-exit availability for processor-time properties on Windows vs Unix.
• Updates Process.StartTime and Process.ExitTime XML docs to document caching/exception behavior.

Reviewed changes

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

Show a summary per file

File	Description
src/libraries/System.Diagnostics.Process/tests/ProcessTests.cs	Adds a new test exercising timing properties after process exit across Windows/Unix.
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.cs	Documents StartTime caching behavior and ExitTime summary/exception behavior.
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Windows.cs	Documents that processor-time properties remain retrievable after exit on Windows.
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Linux.cs	Documents that processor-time properties are unavailable after exit on Linux.
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.OSX.cs	Documents that processor-time properties are unavailable after exit on macOS.
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.FreeBSD.cs	Documents that processor-time properties are unavailable after exit on FreeBSD.
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.OpenBSD.cs	Documents that processor-time properties are unavailable after exit on OpenBSD.
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.SunOS.cs	Documents that processor-time properties are unavailable after exit on SunOS.

[adamsitnik]

@copilot please address the feedback

[azure-pipelines]

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

[adamsitnik]

lgtm

[tannergooding]

LGTM, but I agree that Jan's feedback on terminology should be addressed

[jkotas]

@adamsitnik Don't forget about the backport to https://github.com/dotnet/dotnet-api-docs/ . It won't happen automatically. Asking copilot to create the backport PR works great.

[adamsitnik]

@adamsitnik Don't forget about the backport to https://github.com/dotnet/dotnet-api-docs/ . It won't happen automatically. Asking copilot to create the backport PR works great.

Thanks for the reminder, I assumed somebody owns this process. I've opened dotnet/dotnet-api-docs#12887 and foremost dotnet/dotnet-api-docs#12888 to backport all the docs for new APIs