Add whiteboard frame mode (Nextcloud Whiteboard / Excalidraw over WebDAV)

New third mode alongside photos/calendar: fetches a .whiteboard file
over plain WebDAV (Basic auth -- generic, not Nextcloud-specific) and
renders it via a small Node.js sidecar using Excalidraw's own real
export code (@excalidraw/utils + @resvg/resvg-js, no headless browser),
since a .whiteboard file turns out to be Excalidraw scene JSON, not an
image. The sidecar runs as a second process inside this same container
(Dockerfile installs Node, start.sh backgrounds it before exec'ing
uvicorn) rather than a separate docker-compose service -- lightweight,
stateless, reachable only at 127.0.0.1 from the Python process, nothing
worth independently scaling.

The rendered PNG is treated exactly like a photo from there on --
composed/quantized through the existing image_pipeline (letterboxed,
never cropped) rather than a second parallel rendering pipeline.

WebDAV credentials support the common "it's actually the same Nextcloud
account as my CalDAV" case (an explicit opt-in checkbox, not silently
inferred) while still working with any WebDAV server generically.
Frame-level source (URL + owning account) follows the same owner-
controls-their-own-data permission split as calendar sources and the
week view's task list: only the account owner can point a frame at it,
anyone linked can clear it.

Honest limitation: this environment has no Node.js/npm, so
render-service/ is written carefully against each library's documented
API (verified via the npm registry, including transitive dependency
licenses after the CalDAV/AGPL surprise earlier this session) but has
never actually been executed. First real docker build is the first
true test -- see render-service/README.md.

server/render-service/README.md

@@ -0,0 +1,33 @@
+# whiteboard-render
+
+Local sidecar for whiteboard frame mode -- see `server.js`'s own header
+comment for the full "why Node, why not a headless browser" reasoning.
+Not an independently deployed service: it runs as a second process
+inside the main server's container (`../Dockerfile` installs Node,
+`../start.sh` launches this in the background before `exec`-ing
+uvicorn), reachable only at `127.0.0.1:3001` from the Python process in
+that same container.
+
+**Not runtime-tested against a real `npm install` during development**
+-- this environment had no Node.js/npm available, only the npm registry
+API (used to verify the dependency versions/licenses in `package.json`
+actually exist and resolve). The code is written carefully against each
+library's documented API (`@excalidraw/utils`'s `exportToSvg`,
+`@resvg/resvg-js`'s `Resvg` class), but the first real build
+(`docker compose build`) is the first time this has actually executed
+end to end. If something's off, `docker compose logs` will show it --
+most likely candidates are `exportToSvg`'s actual return type (string vs.
+DOM element -- handled defensively, see server.js) or a font-rendering
+quirk, not a wrong API shape.
+
+## Local development (if you have Node 20.19+/22.13+ installed)
+
+```sh
+cd render-service
+npm install
+npm start          # listens on 127.0.0.1:3001
+curl -X POST http://127.0.0.1:3001/render \
+  -H "Content-Type: application/json" \
+  -d '{"elements": [], "width": 800}' \
+  -o /tmp/test.png  # an empty scene -- just checks the service comes up and returns a valid PNG
+```