This resonates. A lot of the friction you're describing comes from asking the runtime to behave like a long-lived server on a machine that's fundamentally a client. Cold boots per command, autoload cost, background orchestration, those are what you hit when the device is treated as the application host rather than as a client talking to one.

I ran into the same wall and it pushed me to write down the mindset explicitly: on-device PHP is client-side, full stop, same trust level as JavaScript in a browser tab. The clearest tell is now(), on a server it's a fact, on the device it's whatever the user set in Settings, so trial expiry and token TTLs can't be enforced there at all. I wrote it up here if it's useful: https://github.com/NativeBlade/NativeBlade/discussions/53

The way I ended up handling the heavy always-on work you mentioned (queues, scheduling, long processes) was to keep it off the PHP layer entirely, a native courier/background-task layer in Rust does it, and the on-device PHP stays the frontend. Curious whether you landed somewhere similar or went a different direction with the background stuff?