Fix Windows process group example: CTRL_BREAK_EVENT, not CTRL_C_EVENT

[Copilot]

GenerateConsoleCtrlEvent with CTRL_C_EVENT silently succeeds but delivers no signal when the target process group ID is non-zero. The example was broken by design.

Changes

• Parent: CTRL_C_EVENT → CTRL_BREAK_EVENT — the only valid choice when targeting a non-default process group
• Child signal handler: PosixSignal.SIGINT → PosixSignal.SIGQUIT — on Windows, SIGQUIT maps to CTRL_BREAK_EVENT; SIGINT maps to CTRL_C_EVENT
• Child setup: Removed SetConsoleCtrlHandler(NULL, FALSE) call — CREATE_NEW_PROCESS_GROUP disables CTRL+C, not CTRL+BREAK, so re-enabling isn't needed here; updated comment to explain the distinction and note when the call is required

// Before (broken — silently does nothing for non-zero process group IDs)
GenerateConsoleCtrlEvent(CTRL_C_EVENT, (uint)process.Id);

// After
GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, (uint)process.Id);

[Copilot]

Pull request overview

This PR fixes the .NET 10 “Windows process management” snippet so it can actually signal a child process launched in a non-default process group. It updates the parent to use CTRL_BREAK_EVENT (instead of CTRL_C_EVENT), aligns the child’s managed signal handler with that event, and removes an unnecessary SetConsoleCtrlHandler call while clarifying the behavior in comments.

Changes:

• Send CTRL_BREAK_EVENT from the parent when targeting the child process group.
• Handle CTRL+BREAK in the child via PosixSignal.SIGQUIT and update the log message accordingly.
• Remove the SetConsoleCtrlHandler(NULL, FALSE) call and replace it with a clearer explanation of when it’s needed.