The distinction comes down to what each mechanism talks to.
Sleep is managed by the Windows power manager. An application can hold a power request telling it that the system or the display must remain available. The power manager honours it and the machine stays up. No input is involved anywhere in that exchange.
Idle time is tracked separately, from input events. Windows records when input last arrived, and any application can ask how long ago that was. Collaboration apps use it to decide when you have stepped away. Because a power request produces no input events, that timer keeps counting up while a request is held — which is correct behaviour, not a bug. You genuinely have not touched the machine. The operating system is reporting the truth.
So a keep-awake tool and a presence tool are solving different problems, and no amount of holding power requests will affect a status indicator. Anything claiming a power request keeps you "available" is either mistaken or describing synthetic input without saying so.
What actually resets the idle timer is injected input. That is what mouse jigglers do, and it works. It is also flagged: Windows marks injected input at the OS level and any monitoring tool can read that flag, so it is not stealthy regardless of how gentle the input is.
StayGreen's position on this is deliberately awkward, and stated rather than hidden. It includes an optional presence mode that sends a single innocuous key signal on a slow interval. It is off by default. It cannot be turned on without an explicit consent step, and that consent is re-validated whenever settings are loaded or saved, so it cannot be enabled by hand-editing a configuration file. It only emits while a power request is actually held, never while the session is locked, and only within optional active hours you set. The interface says outright that the input is detectable by monitoring software, shows an advisory while it is active, and offers a "turn off and forget my consent" action. That posture exists because the feature has real policy implications and a tool that buried it would be setting people up.
Practical guidance. If your problem is sleep, you need the keep-awake behaviour, and it involves no synthetic input at all. If your problem is a status icon, understand that any solution to it works by faking activity, that this is detectable, and that your workplace may have a view on it. Those are different decisions and worth making separately.
One related limitation, while being straight about boundaries: on hardware using Modern Standby, the system can take over on battery regardless of what an application requests. No application overrides that.