[Feature]: Server-Side Slicing on linux/arm64 systems (#1900)

    * Add override file for ARM64 setups.

    This commit adds an override file which explicitly specifies the container platform to be linux/amd64.
    It forces docker to pull/build/run the amd64 image (even on arm64 hosts).
    Assuming binfmt support is set up, this will run the amd64 applications via emulation.

    * Add arm64 override file information to README.

    Adds a section covering the experimental setup for
    arm64 hosts to the README.

    * Make the ARM64 override survive the next compose command (#1900)

    The override only applies while both -f flags are on the command line, and
    every other instruction in this README is written bare. An ARM64 user who
    followed the update steps would drop the platform pin without noticing: a
    manifest error today, and a silent switch off emulation once native ARM64
    images ship. The quick start now writes COMPOSE_FILE into .env, so the rest
    of the file works unchanged on ARM64 -- verified both ways, with and without
    that line.

    Two things the setup needs stated where it is read rather than one hop away
    in the wiki: binfmt has to be registered on the host or the container dies
    with "exec format error", and emulation costs roughly 3-6x native slice
    time. Both now lead the section, and the separate-x86_64-box route stays the
    recommendation it was -- emulation is the fallback for people who have no
    second machine, not a replacement.

    The compose file's own header said ARM64 was a dead end. It now points at
    the override, for anyone who reads the stack instead of the README.

slicer-api/README.md

@@ -38,6 +38,11 @@ at all. For ARM64 hosts (Raspberry Pi 4/5, Apple Silicon Linux), run
 the sidecar on a separate x86_64 box and point Bambuddy at it via the
 **Sidecar URL** field — the sidecar doesn't need to live next to Bambuddy.
 
+If a separate x86_64 box isn't an option, the amd64 images can be run on
+an ARM64 host under emulation — experimental, roughly 3-6x slower than
+native, and a stopgap until native ARM64 images ship. See
+[Experimental setup for ARM64](#experimental-setup-for-arm64) below.
+
 ## Ports
 
 | Service | Default host port | Why this port |
@@ -114,6 +119,48 @@ To roll back to the sidecar that shipped with a previous Bambuddy
 release, set `SIDECAR_TAG=bambuddy-X.Y.Z` in `.env` and re-run the two
 commands above.
 
+## Experimental setup for ARM64
+
+Runs the `linux/amd64` images on an ARM64 host under QEMU emulation, via
+the `docker-compose.arm64.yml` override in this folder. Expect roughly
+3-6x slower slicing than native, worsening with model complexity. This is
+a stopgap until native ARM64 images ship, not a replacement for running
+the sidecar on an x86_64 box — if you have one, use it.
+
+**Set up QEMU binfmt on the host first**, or the containers fail with
+`exec format error`. On Debian/Ubuntu that is `qemu-user-static` plus
+`binfmt-support`; Docker Desktop on Apple Silicon already has it. The
+per-distribution commands are in the
+[wiki](https://wiki.bambuddy.cool/features/slicer-api/) — do that before
+the steps below.
+
+### Quick start for ARM64
+
+```bash
+cd slicer-api/
+cp .env.example .env       # edit ports if you like
+
+# Make every later `docker compose` command pick up the ARM64 override:
+echo 'COMPOSE_FILE=docker-compose.yml:docker-compose.arm64.yml' >> .env
+
+# OrcaSlicer only (default profile):
+docker compose up -d
+curl http://localhost:3003/health
+
+# Both slicers:
+docker compose --profile bambu up -d
+curl http://localhost:3001/health   # bambu-studio-api
+curl http://localhost:3003/health   # orca-slicer-api
+```
+
+That `COMPOSE_FILE` line is what makes the rest of this README work
+unchanged on ARM64 — **Updating** included. Without it every command has
+to name both files (`docker compose -f docker-compose.yml -f
+docker-compose.arm64.yml …`), and the first bare `docker compose pull` or
+`up -d` drops the override: on a host with no amd64 emulation registered
+for that image you get a manifest error, and once native ARM64 images
+exist you would silently switch between them and back.
+
 ## Troubleshooting
 
 - **`address already in use` on port 3000 or 3002** — Bambuddy's

slicer-api/docker-compose.arm64.yml

@@ -0,0 +1,27 @@
+# Override file for the slicer-api sidecar stack on ARM64 (experimental).
+#
+# Pins both sidecars to the linux/amd64 images so they run under QEMU
+# emulation on an ARM64 host. The host must have QEMU binfmt registered
+# first (qemu-user-static + binfmt-support on Debian/Ubuntu) or the
+# containers fail with "exec format error". Expect roughly 3-6x slower
+# slicing than native — a stopgap until native ARM64 images ship.
+#
+# This file is not meant to be used on its own. It is intended to be used in
+# combination with the default docker-compose file, for example:
+#   docker compose -f docker-compose.yml -f docker-compose.arm64.yml up -d
+#
+# Both -f flags are needed on EVERY compose command, not just the first, so
+# put this line in .env instead and the plain commands in the README work
+# unchanged:
+#   COMPOSE_FILE=docker-compose.yml:docker-compose.arm64.yml
+#
+# For any setup questions, see the 'Server-Side Slicing (Slicer API)' page in
+# the Bambuddy wiki. Also check the README and default compose file in this
+# directory for usage instructions and other details.
+
+services:
+  orca-slicer-api:
+    platform: linux/amd64
+
+  bambu-studio-api:
+    platform: linux/amd64

slicer-api/docker-compose.yml

@@ -28,7 +28,10 @@
 #
 # Both images are linux/amd64 only. OrcaSlicer's ARM64 path is on hold
 # pending an upstream extraction fix; BambuStudio doesn't publish ARM64
-# at all.
+# at all. ARM64 hosts are best served by running the sidecar on a separate
+# x86_64 box; failing that, `docker-compose.arm64.yml` in this directory
+# runs these same images under QEMU emulation — experimental, ~3-6x slower,
+# and it needs binfmt set up on the host. See the README.
 
 services:
   orca-slicer-api: