docs: say the published image renders documents on a Raspberry Pi 4

The image runs the glibc canvas build now, which needs no ARMv8.2
features, so the Pi 4 gets thumbnails and scanned-PDF rendering back
without a code change: the gate only ever closed for musl on arm64. The
gate's comment, the env example and the getting-started prerequisites
say so, and keep NATIVE_CANVAS as the override. The x64 AVX2 gate stays:
the glibc x64 build rendered a PDF page under an emulated core without
AVX2, but it still carries AVX2 code and that one run does not cover
every path.

src/lib/documents/native-canvas-support.ts

@@ -1,13 +1,19 @@
 /**
  * v1.28.27 — CPU-feature gate for the native canvas renderer.
  *
- * The bundled `@napi-rs/canvas` (Skia) x64 builds use AVX2 instructions. On an
+ * The `@napi-rs/canvas` (Skia) x64 builds carry AVX2 instructions. On an
  * x86-64 host WITHOUT AVX2 — Celeron/Atom-class NAS CPUs (Goldmont Plus and
- * older) are the common self-hosting case — the first canvas call dies with
- * SIGILL (`trap invalid opcode … in skia.linux-x64-musl.node`), which kills the
- * whole Node process and puts the container into an infinite restart loop
- * (live incident: a Synology DS1520+ self-host, exit code 132 ~18 s after
- * every boot once the thumbnail backfill touched Skia).
+ * older) are the common self-hosting case — the musl build died on the first
+ * canvas call with SIGILL (`trap invalid opcode … in skia.linux-x64-musl.node`),
+ * which kills the whole Node process and puts the container into an infinite
+ * restart loop (live incident: a Synology DS1520+ self-host, exit code 132
+ * ~18 s after every boot once the thumbnail backfill touched Skia).
+ *
+ * The published image is Debian (glibc) and runs the glibc build. Under an
+ * emulated AVX2-less Atom core that build drew a canvas and rendered
+ * a PDF page to JPEG where the musl build died, but it still carries AVX2 code
+ * and not every path it can take was exercised, so the x64 gate stays closed
+ * without the flag. `NATIVE_CANVAS=on` is the way to try it on such a host.
  *
  * A SIGILL cannot be caught in-process, so the only safe posture is to never
  * load the module on an unsupported CPU. Every canvas consumer (document
@@ -15,12 +21,13 @@
  * the gate closed those features degrade cleanly (no thumbnails, PDFs read as
  * text/native only) while the rest of the app runs normally.
  *
- * The arm64 musl build (the one the published arm64 image runs) is compiled
- * for ARMv8.2 and later: it uses LSE atomics (`ldaddal`, `casal`) and RCpc
- * loads (`ldapr`) throughout, with no runtime fallback, and dies with SIGILL
- * as soon as the module loads on an ARMv8.0 core such as the Raspberry Pi 4's
- * Cortex-A72. The glibc arm64 build uses neither, so a glibc host is left
- * alone.
+ * The arm64 musl build is compiled for ARMv8.2 and later: it uses LSE atomics
+ * (`ldaddal`, `casal`) and RCpc loads (`ldapr`) throughout, with no runtime
+ * fallback, and dies with SIGILL as soon as the module loads on an ARMv8.0
+ * core such as the Raspberry Pi 4's Cortex-A72 (#1311). The glibc arm64 build
+ * uses neither and runs there, which is why the published image moved off
+ * Alpine. The musl branch stays for a host that runs the app on musl itself,
+ * from source on Alpine or from an image built on it.
  *
  * Detection reads `/proc/cpuinfo` once on Linux: x64 requires the `avx2`
  * flag, arm64 under musl requires the `atomics` and `lrcpc` features. Every