Reload page on system resume to fix stale Messenger connection

[worthyfarmstead-rgb]

Summary

After a system suspend/wake cycle, the long-poll/WebSocket connection to messenger.com is silently broken — no new messages arrive and sends fail until the user manually presses Cmd+R. This is a known issue noted in the code itself (the electronDebug call at the top of index.ts explicitly keeps debug mode on for this reason).

Fix

Listen for Electron's powerMonitor resume event. When the system wakes:

1. Wait for network connectivity via the existing ensureOnline() utility (polls every second with p-wait-for + is-online) to avoid a blank page on slow reconnects — as raised by @veniversum in the issue thread.
2. Reload the webContents to re-establish the Messenger connection.

powerMonitor.on('resume', async () => {
    await ensureOnline();
    webContents.reload();
});

No new dependencies. Uses only Electron built-ins and the already-imported ensureOnline helper.

Testing

1. Open Caprine and confirm messages load.
2. Put the machine to sleep (close lid or pmset sleepnow).
3. Wake the machine.
4. Verify new messages arrive without a manual reload.

Fixes #103

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8bd020aef9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid interactive offline prompt in resume handler

Calling ensureOnline() in the powerMonitor resume callback makes every wake-from-sleep path inherit startup behavior that shows a synchronous “Wait/Quit” dialog (and can call app.quit()) when connectivity is missing for ~15 seconds. In practice, users who resume without network (airplane/train, captive portal, Wi‑Fi still reconnecting) can get an unexpected blocking prompt or have the app quit even though they did not explicitly relaunch; this is a regression in the resume flow and should use a non-interactive connectivity wait/fallback.

Useful? React with 👍 / 👎.