OpenScrub v1.0.82

OpenScrub 1.0.82 — two bugs that made a healthy app look broken

Two fixes in this release came straight from user issue reports — thank you to the reporters. Both failure modes are the kind that look like "the app is broken" while the app is fine, which makes them worse than crashes.

Fixed: Docker containers looked dead on macOS/Windows (#15)

A Mac user ran the CPU image and got nothing: empty docker logs, no web response. The container was healthy the whole time — two bugs hid it:

•	Logs were invisible. Python buffers stdout in a non-TTY container, so the startup banner (and any crash traceback behind it) sat in a memory buffer instead of reaching docker logs. All three images now set PYTHONUNBUFFERED=1 — logs stream live from the first line.
•	The banner pointed at an unreachable address. It printed the server's detected IP, which inside a container is the internal bridge address (172.17.x.x) — never reachable from a macOS or Windows host, where only the published port works. In container mode the banner now says to open https://localhost:8384/ (with a note about the one-time self-signed-certificate warning) and explicitly warns that the 172.17.x.x address will not work from a Mac/Windows host.
•	New: all three images carry a HEALTHCHECK, so docker ps and Docker Desktop now show whether the server actually answers instead of just "Running".

Fixed: large uploads hit a silent 8 GB wall (#14)

An 18 GB license-plate job died with a bare "413 Request Entity Too Large". The limit was hard-coded; now it's a dial:

•	--max-upload-gb N on openscrub-web, or OPENSCRUB_MAX_UPLOAD_GB=N as an environment variable (Docker-friendly). 0 = unlimited. The default stays 8 GB.
•	The editor now checks the file size against the server's limit before uploading, so a doomed multi-hour upload is refused at click time with instructions instead of failing at the end.
•	The 413 response itself explains both ways forward.
•	For files that size, the better route is documented prominently: put the file where the server can read it (in Docker, mount the folder read-only) and use the "path on the server" box — the server processes it in place and nothing crosses the network, with no size limit involved.

Both fixes are covered in two new rows of the README's Tuning cheat sheet.