Add the REST plug lifetime-counter fix to the changelog (#3233)

CHANGELOG.md

@@ -99,6 +99,7 @@ All notable changes to Bambuddy will be documented in this file.
 - **The frontend build no longer warns about `path` and `crypto` being externalized for the STEP previewer (#2976)** — `occt-import-js`, the Emscripten build behind STEP previews, requires both modules, but only inside its `ENVIRONMENT_IS_NODE` branches; in the browser it loads its `.wasm` from the URL the preview worker passes and draws randomness from `crypto.getRandomValues`. Vite still externalized both and printed two warnings on every build. `vite.config.ts` now drops exactly those two warnings for that one package through `build.rolldownOptions.onLog`, so an externalization anywhere else, or of any other module, still shows.
 
 ### Fixed
+- **The Statistics energy total stayed at 0 for Shelly and other REST plugs with only a lifetime counter (#3232, reported and contributed by @rojosinalma in #3233)** — With **Total consumption** tracking and no date filter, the Statistics page adds up each plug's lifetime counter, but for REST plugs it added the counter for today. Since #2539, a Shelly is set up with only **Lifetime Energy JSON Path**, as it has no counter for today, so its plug added nothing and the energy total and cost showed 0, while any date range showed the right figure. REST plugs now add their lifetime counter, the same as Tasmota and Home Assistant plugs. A plug with only a counter for today still adds that one.
 - **Running out of file descriptors could corrupt a SQLite database (#2883, reported and contributed by @M2ABRAMSTANK in #2884)** — Docker, the systemd service and most native installs start Bambuddy with a limit of 1024 open files. Once a busy instance used them all, every new database connection failed with "disk I/O error"; on the reporter's single-printer install that went on for 44 hours and ended with "database disk image is malformed" and a login outage. Part of the reason is how SQLite works in WAL mode: a database connection that closes keeps its file open until the last connection closes, so the database's share of open files stays at the most connections the pool ever reached. Bambuddy now raises its own open-file limit to the maximum the system allows when it starts, on every install, and logs what it set. The SQLite connection pool is smaller (10 + 90 instead of 20 + 200), which halves its share. A large printer farm still on SQLite that runs out of connections can raise `DB_MAX_OVERFLOW`, but is better served by PostgreSQL. The support bundle now counts open files by kind (database, sockets, pipes and so on) against the limit, so the next report shows what is holding them. Covered by backend tests.
 - **One model queued to several printers could print in the wrong filament (#2799, reported and contributed by @grolmus in #2803)** — An AMS mapping is a list of one printer's own tray numbers, and Bambuddy stamped the mapping it worked out for the first selected printer onto every other printer in the same dispatch. Where those printers hold the same spools in a different slot order the tray numbers still resolve, so nothing looks wrong, and each copy prints from whatever sits in that tray — in the reported case ASA where the 3MF requires PETG. An explicit mapping also bypasses the printer's own filament-type check, so nothing further down catches it. Every selected printer is now mapped against its own AMS, and a mapping already stored on a queue item is checked against the printer about to run it and recomputed when it does not fit, which covers a spool moved between queueing and dispatch as well. A tray of the right type in the wrong colour is still accepted, as it always was when nothing better is loaded. A slot you put on a tray of another material yourself in the print dialog is kept as you chose it.
 - **A job whose filament is not loaded waits instead of printing (#2799, reported and contributed by @grolmus in #2803)** — When a slot the plate prints cannot be matched to a tray on the printer it is about to go to, the job is held for a manual start and the queue row says which filament it needs, the same way a job short of filament already waits. This also catches a job that matched nothing at all: it used to be sent anyway and refused by the printer after the whole file had been uploaded, with `0700_8012 Failed to get AMS mapping table` and no explanation on screen. A job queued to a model rather than a named printer gives its printer back when it is held, so pressing start lets the queue choose among all printers of that model again instead of tying the job to the one that could not run it. That choice still goes by filament type only, so when the filament is on the wrong nozzle or the AMS changed after the printer was picked, it can pick the same printer and hold the job there again. A held job waits for someone to press start even once the right spool is loaded, as the filament-shortage hold already does. Start then finds the spool and the job prints, keeping any trays already chosen for its other slots. If the filament is still not loaded, Start says which one is missing and offers Print Anyway, which sends the job the way it went out before this change. The filament named on the queue row and in the notification is in English whatever the interface language.