Updated CHANGELOG

CHANGELOG.md

@@ -20,6 +20,8 @@ All notable changes to Bambuddy will be documented in this file.
 
 - **An API key can now read and run slicer pipelines (raised on Discord)** — Every pipeline endpoint answered `403 API keys cannot be used for administrative operations`, whatever scopes the key carried, so a pipeline could only ever be triggered by a signed-in person clicking Run. That was not a judgement about pipelines: the first pipelines release shipped only the authoring screens, with the run dispatch still to come, so all three permissions were parked as administrative until there was something to decide about. The dispatch landed in the release that followed and the parking was never revisited. Listing pipelines and reading run history now come with **Read Status**, and starting, cancelling or retrying a run needs **Manage Queue** and **Manage Library** *together* — a run does both of those jobs, slicing the source into a new library file and then queueing one print per copy, and neither toggle on its own authorises the whole operation. A key holding just one of them is refused with the other named in the response, rather than being told to go and find an administrator. This grants no capability a key did not already have: one holding both toggles could always slice a library file and queue prints as separate calls, and a pipeline only composes those two steps using slicer settings and a target an administrator authored. Authoring stays administrative — a key can run the recipe but cannot rewrite it, or clear the runs log — so `pipelines:write` still rejects every key. A pipeline whose presets come from Bambu Cloud or Orca Cloud needs one thing more: resolving those reads a cloud token off a user record, and the permission gate hands an API-keyed request no user at all, so such a run would have had nobody to resolve against and would have failed at slice time. It now falls back to the key's owner, which is the same fallback slicing a library file directly has made since #1182, and it applies only to keys that carry **Allow Cloud Access** — every other key slices against local presets exactly as before. Existing keys need no changes and nothing is backfilled, since this rides toggles that already exist. Wiki updated. Covered by backend tests.
 
+- **Server-side slicing on an ARM64 host, for people with no x86_64 machine to point it at (#1821, contributed by @Felix-Rm)** — Both slicer sidecars ship as `linux/amd64` images and nothing else: OrcaSlicer's community ARM64 AppImage fails to extract under QEMU build emulation, and Bambu Studio publishes no ARM64 build at all, on any platform. That left ARM64 owners — a Pi 5, an ARM NAS, an Ampere VM — with one route to server-side slicing, which was to run the sidecar on a separate x86_64 box and point Bambuddy at it over the network. That is still the recommendation, because it is the only one that runs at full speed. For anyone with no second machine to spare, `slicer-api/docker-compose.arm64.yml` now pins both sidecars to the amd64 images so they run on the ARM64 host itself under QEMU, and it is proven on real hardware rather than assumed: a Debian 12 / RK3588 board slicing the same models as an amd64 box. It is a separate override file rather than two lines in the default compose file, for three reasons. It is slow — 3-6x native on that RK3588, worse as models get more complex, and an RK3588 is at the fast end of ARM SBCs, so a typical ARM NAS fares worse still. It needs QEMU binfmt registered on the host first, which not every appliance NAS will allow, and without it the containers die with `exec format error` — a worse failure than today's clear pull-time "no matching manifest", so it must be chosen deliberately rather than inherited. And a platform pin in the default file would silently keep every ARM64 user on emulation the day native ARM64 images do ship. Opting in is one line in `.env` (`COMPOSE_FILE=docker-compose.yml:docker-compose.arm64.yml`) so that every later `docker compose pull` and `up -d` keeps the override instead of quietly dropping it — the failure that recipe exists to prevent. The prerequisites, the per-distribution binfmt commands and the performance expectation are in the README and the wiki.
+
 ### Changed
 - **A filament whose exact colour is not loaded now prints in the closest one available, not the first one within tolerance (#2804)** — When a file asks for a colour no spool matches exactly, the matcher falls back to spools that are close enough. It picked whichever of those came first in AMS slot order, so the winner depended on which slot a spool happened to sit in: a required `#3A7BD5` with a purple `#6253AD` in tray 1 and a near-identical `#3B7AD2` in tray 3 took the purple, and moving the spools between slots changed the outcome with nothing else changed. Eligible spools are now ranked by how close they actually *look*, and the nearest wins. Closeness is measured with CIEDE2000, the CIE's perceptual colour-difference formula, rather than by subtracting the RGB numbers — those two disagree often enough to matter, because RGB arithmetic overstates blue badly: against a dark green requirement it rates a purple as the nearer of two eligible spools and a green as the further one. Which spool qualifies as close enough is unchanged — the same per-channel tolerance as before — so no spool becomes usable or unusable because of this, only better or worse ranked among those already eligible. **This changes which spool some prints use.** If **Prefer Lowest Filament** is on, its ordering previously decided the fallback outright, and it now acts as the tie-break between spools that are equally close, on the grounds that printing in the right colour matters more than burning down a part-used spool, and that two equally close spools is the case that preference was actually for. Alpha is still ignored on both sides, so a transparent filament keeps matching its own colour. The four places that pick a spool — the scheduler's matcher and the three in the interface — now share one ranking rule instead of carrying four copies of it, which is what allowed them to disagree. The scheduler also logs which rule won for every slot it maps, and the colour distance when the winner was a near-match, rather than only doing so when Prefer Lowest was switched on; "why did it pick that spool" is answerable from the log now. Covered by backend and frontend tests.
 - **Preheat no longer gives up on a chamber-heated print whose file carries no bed temperature (#2727, contributed by @ticfinack)** — Preheat read its bed target out of the slicer metadata, and a file that carried none — common in OrcaSlicer's `gcode.3mf` exports — made it skip the whole stage and start the print against a cold chamber, which is the outcome preheat exists to prevent. Where the print needs chamber heat the bed is simply how that heat is produced, so those jobs now heat the bed to the **Keep-warm bed temperature** instead of bailing out. A bed temperature found in the file still wins, and a print with no chamber requirement still skips, so no bed temperature is invented for the print itself; preheat's target is transient either way, since the print's own G-code sets its bed at start. **If you have preheat enabled and your files carry no bed temperature, dispatch will now take noticeably longer than it used to** — those jobs previously skipped straight to the upload and will now wait for the chamber to converge and soak, up to twenty minutes at the default wait and soak settings. This applies only with preheat switched on, and the two settings that govern it are unchanged. In the same pass, preheat gained the soak-crediting described above: on a printer that reports its chamber temperature, a soak the chamber has demonstrably already served is shortened or skipped rather than repeated. Both apply wherever preheat runs, not only under the new keep-warm toggle.