fix: report renderer hangs independently of system sleep and window visibility

[codebytere]

Description of Change

The unresponsive / responsive events on webContents now reflect the renderer, not system sleep or window visibility. Two cases produced events that had nothing to do with the renderer's state, and apps that reload or kill a renderer on unresponsive (or wait for responsive) acted on them:

1. After the system wakes. The input event ack timeout behind unresponsive runs on base::TimeTicks, which keeps counting through sleep on Windows (QPC) but stands still on macOS and Linux. A timeout armed before the machine sleeps therefore fires the moment it wakes, while every process is still paging back in, and the renderer is reported unresponsive. Chromium's GPU watchdog already pauses across suspend for this reason; the renderer hang monitor has no power awareness. WebContents::RendererUnresponsive() now checks base::PowerMonitor: while the system is suspended, or within input::kHungRendererDelay of the last resume, it runs the hang-monitor restarter it is handed instead of emitting, so a renderer that is still stuck a full delay after the wake is reported as before.

2. When a hung window is hidden. RenderWidgetHostImpl::WasHidden() stopped the timeout with StopInputEventAckTimeout(), which also declares the renderer responsive. Minimizing, occluding or screen-locking a hung window therefore emitted responsive with no recovery behind it and cleared the unresponsive state, so the real recovery later emitted nothing. WasHidden() now pauses the timeout without touching responsiveness (a PauseInputEventAckTimeout() split out of StopInputEventAckTimeout(), added to the existing refactor_unfilter_unresponsive_events.patch); WasShown() re-arms it for a widget that is still hung, and a real input ack still emits responsive, hidden or not. Chrome relies on the old behavior only to dismiss its hung-page dialog on tab backgrounding, which Electron does not build.

	before	after
input pending, system sleeps and wakes (Windows)	unresponsive ~1 s after wake	nothing unless still hung 15 s after wake
hung window is minimized / occluded	responsive immediately; nothing when it actually recovers	nothing on hide; unresponsive again when shown if still hung; responsive when it recovers

The testing-only binding gains simulatePowerEvent('suspend' | 'resume') (drives base::PowerMonitorSource::ProcessPowerEvent) so the spec can exercise the resume path.

Checklist

• PR description included and stakeholders cc'd
• npm test passes (new webContents module > unresponsive event cases: not emitted within a hang delay of a resume; no responsive on hide, unresponsive again on show, responsive on recovery; baseline hang still reported; each fails with its fix reverted)
• Relevant documentation is changed or added (behavior fix; unresponsive/responsive docs unchanged)
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.
• I have reviewed and verified the changes

Release Notes

Notes: Fixed webContents emitting unresponsive right after the system wakes from sleep on Windows, and emitting responsive when a hung window was hidden rather than when it recovered.