The till stays awake while it trades, and catches up the moment it wakes

[sridharkalaibala]

Stage 7 of the print roadmap. The one failure that needs no queue to hurt.

What was happening

Windows sleeps an idle machine, and a restaurant till is idle for long stretches
between services. The moment it suspends, the kitchen stops receiving tickets
and handsets stop reaching it — while the screen still says Posnic and nothing
reports a fault. The waiter presses send, the phone says sent, no paper comes
out. Nobody finds out until somebody walks to the printer.

"desktop app system got logged out or screen lock, then also our app should
keep wake."

Locking is not sleeping

Worth being exact, because the two get conflated and it sends a shop hunting the
wrong fault:

Screen locked	session keeps running, printing continues. Fine, and worth encouraging.
Machine asleep	process, network and printer all stop. This is what's blocked now.
Logged out	session ends. Still fatal — that's Stage 8, and probably never.

A lock is logged saying the till kept running, so "it stopped when I locked it"
has an answer in the log rather than a shrug.

What is held, and what is not

prevent-app-suspension, never prevent-display-sleep. The system is kept
from suspending; the screen may still blank, and should — a kitchen display that
can never blank is one that burns in.

The block is released on shutdown. A till that looks switched off and still
refuses to sleep is a machine nobody can explain.

The wake-up is where duplicates come from

A till asleep for two hours wakes with work behind it and a 30-second poll that
did not run while it was suspended. Thirty seconds at a pass with no ticket is
how a cook reprints by hand — and that is how a wake-up becomes the duplicate
this whole area exists to prevent.

So every collector runs on resume rather than at the next timer:

kotManager._poll();        // kitchen tickets
billManager._poll();       // floor bills
billManager._pollCloud();  // cloud-relayed bills

One failing task cannot stop the others — the point of the moment is that
everything catches up at once — and a rejected promise is caught, because an
unhandled rejection on a till is a crash dialog in a restaurant.

It cannot stop a till starting

powerSaveBlocker is genuinely absent under some remote sessions, so every call
answers instead of throwing, the module loads with no Electron at all, and the
startup call sits inside a try. A test pins each of those.

Desktop 2530 pass / 0 fail.

Next in this run

needs_attention on the print queue, then kitchen tickets through the queue
itself — shadowed alongside the existing poll, not swapped.

[github-actions]

Merged to develop. Anyone can test this - you do not need write access.

Try it at https://develop.posnic.io, or run it yourself:

git fetch origin develop && git checkout develop
npm install && npm --prefix api install
npm run dev   # then http://localhost:3000

When you have tested it, say what you did and what happened, and set
QA passed or QA failed. If you cannot set labels, just comment -
a maintainer will.

Reporting that something is broken is as useful as fixing it. It is
better found here than by a shopkeeper.