v1.19.1 — Docker image serves fcaptcha.js again

Patch release. If you run the Docker image, update.

The bug (#23, reported by @pnlx)

/fcaptcha.js returned 404 on every published image, so the widget could not be loaded from a container without setting FCAPTCHA_CLIENT_PATH by hand. Reproduced on 1.17.0, 1.18.0 and 1.19.0.

The image copies the widget to /app/static/fcaptcha.js, and the server's path resolution did not include that location.

The demo page in the image loads the widget from /fcaptcha.js, so it was affected too.

The fix

Three candidate paths, including the image's static/ layout. Verified against a built image with no configuration:

/fcaptcha.js  ->  HTTP 200, 118,245 bytes
/demo/        ->  HTTP 200, widget resolves
startup log:  serving /fcaptcha.js from /app/static/fcaptcha.js

The FCAPTCHA_CLIENT_PATH=static/fcaptcha.js workaround still works and is no longer needed.

Why it will not happen again

Unit tests now cover the Docker layout, the repo layout, the env override, and one that fails if the Dockerfile stops copying to static/fcaptcha.js.

A CI job also builds the image, starts it, and asserts /fcaptcha.js serves the widget and the demo page's script reference resolves — verified to fail against a broken build.

Everything else

No detection, scoring or API changes. Identical behaviour to v1.19.0 outside the container.