fix: first-run QA sweep of the single-container image (#413)

Fixes found by manually testing a fresh install end to end:

- auth: the must-change-password gate returned 403 on public routes
  including /api/v1/health, so every fresh install showed a false
  "Reconnecting to server" banner on the forced password change
  screen. Public routes are now exempt (they need no session at all).
  Adds the gate's first direct tests.
- multipart: @fastify/multipart's parts() iterator (9.4.0 and 10.0.0)
  ends on the request stream's "close", which on a reused keep-alive
  connection fires while an earlier part is still streaming to storage,
  silently dropping the parts behind it. The object eraser lost its
  mask file on every second POST per connection. Replaced with a
  busboy-driven iterator (lib/multipart-parts.ts) that ends on busboy's
  own "finish", installed for all routes via a preValidation hook;
  the tool-factory field-recovery workaround for the same bug is now
  unnecessary and removed.
- eraser: the mask canvas backing store is natural resolution, but
  "absolute inset-0" does not stretch replaced elements, so the
  canvas rendered at intrinsic size and the brush ring, strokes, and
  exported mask were all misscaled on photos larger than the viewport.
  The canvas now gets an explicit CSS box at the fitted size.
- compare slider: solid white divider with a dark halo so it stays
  visible over light images; still initialised at the painted region.
- tool page: the AI bundle install prompt now centers in the content
  area instead of hugging the top.
- api docs: disabled Scalar's cloud features (Ask AI, Generate MCP,
  Open API Client, dev toolbar), hid the "Powered by Scalar" footer
  link, and set the page title to "SnapOtter API Reference". The docs
  CSP blocks those cloud calls by design, so the buttons were dead UI.
- docker: embedded Redis comes from packages.redis.io pinned to the
  8.x major (was Debian's 7.0.15), matching the Compose stack and the
  documented claim. Build fails fast if the major ever drifts.
- docs: DOCKERHUB.md quick start now leads with the one-command docker
  run (matching the README) with Compose as the production path;
  README says embedded Postgres 17 + Redis 8.

Claude-Session: https://claude.ai/code/session_01XGB4pGvTvb7sUX4JN745U7

apps/api/src/lib/multipart-parts.ts

@@ -0,0 +1,99 @@
+import type { Readable } from "node:stream";
+import { Busboy, type BusboyHeaders } from "@fastify/busboy";
+import type { FastifyRequest } from "fastify";
+import { env } from "../config.js";
+
+export interface MultipartFilePart {
+  type: "file";
+  fieldname: string;
+  filename: string;
+  encoding: string;
+  mimetype: string;
+  file: Readable;
+}
+
+export interface MultipartFieldPart {
+  type: "field";
+  fieldname: string;
+  value: string;
+}
+
+export type MultipartPart = MultipartFilePart | MultipartFieldPart;
+
+const DONE = Symbol("multipart-done");
+
+/**
+ * Iterate multipart parts by driving busboy directly.
+ *
+ * Replaces @fastify/multipart's request.parts(): that iterator treats the
+ * REQUEST stream's "close" event as end-of-parts, and on a reused keep-alive
+ * connection the whole body can be read (firing "close") while the consumer
+ * is still streaming an earlier part to storage. Every part busboy emits
+ * after that moment lands behind the end marker and is silently dropped; in
+ * practice the second multipart POST on a warm connection lost its trailing
+ * parts (the object eraser's mask file, then the settings fields). Verified
+ * against @fastify/multipart 9.4.0 and 10.0.0. Busboy's own "finish" fires
+ * only after every part has been emitted, so iteration ends there instead,
+ * and the request stream's "close" is deliberately not treated as an end
+ * signal (a client abort surfaces as an "error" on the stream and as a
+ * truncated-part error from busboy).
+ */
+export async function* multipartParts(request: FastifyRequest): AsyncGenerator<MultipartPart> {
+  const raw = request.raw;
+  const bb = new Busboy({
+    headers: raw.headers as BusboyHeaders,
+    limits: {
+      fileSize: env.MAX_UPLOAD_SIZE_MB > 0 ? env.MAX_UPLOAD_SIZE_MB * 1024 * 1024 : undefined,
+      files: env.MAX_BATCH_SIZE > 0 ? env.MAX_BATCH_SIZE : undefined,
+    },
+  });
+
+  const queue: Array<MultipartPart | Error | typeof DONE> = [];
+  let wake: (() => void) | null = null;
+  const push = (value: MultipartPart | Error | typeof DONE) => {
+    queue.push(value);
+    wake?.();
+    wake = null;
+  };
+
+  bb.on("file", (fieldname, stream, filename, encoding, mimetype) => {
+    // Parity with @fastify/multipart's throwFileSizeLimit default: a stream
+    // that hit the fileSize limit fails its consumer instead of silently
+    // truncating the stored object.
+    stream.on("limit", () => stream.destroy(new Error("request file too large")));
+    push({
+      type: "file",
+      fieldname,
+      filename: filename || "upload",
+      encoding,
+      mimetype,
+      file: stream,
+    });
+  });
+  bb.on("field", (fieldname, value) => push({ type: "field", fieldname, value }));
+  bb.on("filesLimit", () => push(new Error("reached files limit")));
+  bb.on("partsLimit", () => push(new Error("reached parts limit")));
+  bb.on("error", (err: unknown) => push(err instanceof Error ? err : new Error(String(err))));
+  bb.on("finish", () => push(DONE));
+  raw.on("error", (err: Error) => push(err));
+
+  raw.pipe(bb);
+
+  try {
+    while (true) {
+      if (queue.length === 0) {
+        await new Promise<void>((resolve) => {
+          wake = resolve;
+        });
+      }
+      const value = queue.shift();
+      if (value === undefined) continue;
+      if (value === DONE) return;
+      if (value instanceof Error) throw value;
+      yield value;
+    }
+  } finally {
+    raw.unpipe(bb);
+    bb.removeAllListeners();
+  }
+}