When an inhibitor helper dies after startup, NoSleep keeps reporting "Keeping system awake" while the machine can sleep #14

What's wrong

On Linux the inhibitor lock exists only while the helper process is alive. Nothing watches the helper after its first 250 ms:

• NoSleep/Platforms/ChildProcessHold.cs:93 calls WaitForExit(StartupGrace) once. After that the helper is never observed again: no EnableRaisingEvents, no Exited handler.
• NoSleep/Platforms/LinuxSleepBlocker.cs:84-92 reports IsBlocking as holds.Count > 0, whether or not those processes are still running.
• KeepAwakeController.isActive (NoSleep/KeepAwakeController.cs:24) stays true. No StateChanged is raised, so the tray icon and status never change.

Failure scenario

1. On Linux with systemd, enable Keep awake. systemd-inhibit --what=idle:sleep … cat starts running.
2. The helper goes away after the 250 ms startup grace. Causes include pkill systemd-inhibit, an OOM kill, a session-cleanup job, or a late failure in the helper itself.
3. logind releases the lock at that moment.
4. The tray still shows the active icon, and --status still says "Keeping system awake".
5. The machine suspends on idle, which is exactly what the user asked NoSleep to prevent, and nothing tells them.

Why it matters

Silently losing the inhibitor is the worst failure this tool can have, because the UI claims the opposite.

Suggested fix / acceptance criteria

• ChildProcessHold sets EnableRaisingEvents = true and exposes an Exited notification (or a HasExited check).
• LinuxSleepBlocker either drops a dead hold and raises a notification, or re-acquires the lock once.
• KeepAwakeController observes that notification, sets IsActive = false (or re-enables), and raises StateChanged so the tray refreshes.
• Test: run ChildProcessHold over /bin/sh -c "sleep 1". After the helper exits, IsBlocking is false and a state change has been observed. As with the existing tests, the result is inconclusive off Unix.