Right, major progress, I think.
After testing for hours I’ve concluded that the CPU load is directly proportional to the number of .js files in the “tree” loaded by the .js file containing the trigger - in other words, the .js file with the trigger loads some .js files, which load others, which load others. Even if the trigger rule does nothing (all its content is commented out) and even if the trigger never fires, something goes haywire and pegs the CPU at 100%.
So I wondered: what if I just make one huge rule file? I already have a PowerShell script doing various operations on my rule files before deploying them on the Raspberry Pi, so I added another: all the “load” commands pertaining to my own rule files are stripped out, and then all the .js files are concatenated into one huge file.
Result: everything is working. The rules load in seconds, all the timer-based rules are chugging along happily, the HTTP requests work, and the CPU stays at about 4-12%.
So, I’m going to say this is solved, but there appears to be something amiss with the handling of multiple .js files. I don’t know whose department that is, but they might want to take a look at it. I can supply my files if it helps to find the problem.