fix(docker): replace headless-shell with real Chrome so kagane's challenge clears

chromedp/headless-shell cannot clear kagane.to's managed challenge. It is
a stripped Chrome build, and the tells are structural rather than a
header: navigator.webdriver is true, the plugin list is empty, and the
client hints are Chromium- rather than Chrome-branded. Overriding
webdriver through CDP was tried on its own and changed nothing.

Everything below was measured on 2026-08-08 from a single IP, against the
same kagane cover, so the comparisons are like for like:

  chromedp/headless-shell:stable   never cleared (90s)
  zenika/alpine-chrome             never cleared - ships Chrome 124, old
                                   enough that Cloudflare refuses it and
                                   old enough to break chromedp's CDP structs
  google-chrome, default UA        never cleared (60s) - --headless=new
                                   advertises "HeadlessChrome"
  google-chrome, stock UA, UTC     never cleared (90s)
  google-chrome, stock UA, TZ set  cleared in ~4s

So both remaining tells are load-bearing, and each was tested in
isolation. chrome/ is a Debian image with google-chrome-stable, a UA
whose version is read back out of the binary at startup (a hardcoded one
would drift out of step with the Sec-CH-UA hints on the next Chrome
update and become a fresh tell), and no --enable-automation.

The timezone matters because Cloudflare scores a browser whose clock zone
disagrees with its egress IP's country as a proxy. Note that the usual
`-v /etc/localtime:/etc/localtime:ro` does not work here: Chrome resolves
the zone through ICU, which takes the name from that path's symlink
target and ignores the file's contents, so glibc reports the host zone
while Chrome still reports UTC. /etc/timezone carries the name and is
mounted instead; BROWSER_TZ overrides it for a host whose clock is UTC in
a country that is not.

Chrome also binds its DevTools port to loopback and silently ignores
--remote-debugging-address, which is why headless-shell fronted it with
socat. This image does the same, so it stays a drop-in: the compose
service keeps the headless-shell name and its pinned address, and
BROWSER_WS_URL is unchanged.

Deploying needs `docker compose build headless-shell`.

chrome/entrypoint.sh

@@ -0,0 +1,60 @@
+#!/bin/sh
+set -eu
+
+# Cloudflare scores a browser whose clock zone disagrees with its egress IP's
+# country as a proxy, and kagane's challenge then never clears (measured
+# 2026-08-08 from a Thai IP: identical container, UTC never cleared in 90s,
+# Asia/Bangkok cleared in 4s). So the zone has to be right, and it has to be
+# right the way Chrome reads it.
+#
+# TZ must carry the zone *name*. Chrome resolves the zone through ICU, which
+# takes the name from /etc/localtime's symlink target and ignores the file's
+# contents; bind-mounting the host's /etc/localtime therefore lands on the
+# image's own symlink to Etc/UTC and leaves glibc reporting +07 while Chrome
+# still reports UTC. /etc/timezone, mounted by docker-compose.yml, is the name.
+[ -n "${TZ:-}" ] || TZ=$(cat /etc/timezone 2>/dev/null || echo UTC)
+export TZ
+
+# Chrome's own UA advertises "HeadlessChrome" under --headless=new, and that one
+# token is the difference between kagane.to's challenge clearing in ~4s and
+# never clearing at all (measured 2026-08-08, same host, same Chrome, only the
+# UA changed). Overriding it does not touch the Sec-CH-UA client hints, which
+# report the real version, so the version is read back out of the binary rather
+# than hardcoded: a hardcoded one would drift out of step with the hints on the
+# next Chrome update and become a fresh tell.
+major=$(google-chrome-stable --version | sed -E 's/[^0-9]*([0-9]+)\..*/\1/')
+ua="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/${major}.0.0.0 Safari/537.36"
+
+# Chrome binds its DevTools port to loopback and silently ignores
+# --remote-debugging-address (verified 2026-08-08: Chrome 151 with
+# --remote-debugging-address=0.0.0.0 still listened on 127.0.0.1 only), so the
+# caller — another container — cannot reach it directly. socat fronting the
+# loopback port is how chromedp/headless-shell solved the same problem and is
+# why this image is a drop-in for it.
+#
+# Nothing publishes 9222; reachability is the `browser` network in
+# docker-compose.yml, and an exposed CDP endpoint is remote code execution.
+socat TCP-LISTEN:9222,fork,reuseaddr TCP:127.0.0.1:9223 &
+
+# Chrome stays in the foreground so that its death takes the container down and
+# compose's restart policy applies; a backgrounded browser behind a live socat
+# would leave the sidecar looking healthy while answering nothing.
+#
+# No --enable-automation: it sets navigator.webdriver, the first thing a bot
+# check reads.
+#
+# --no-sandbox because Chrome's zygote wants user namespaces, which Docker's
+# default profile does not hand out; the alternative is --cap-add=SYS_ADMIN,
+# which gives the container strictly more than it takes away. Containment here
+# is the unprivileged user, the isolated network, and the fact that this
+# browser only ever navigates to kagane.to and novelfull.com.
+exec google-chrome-stable \
+  --headless=new \
+  --no-sandbox \
+  --remote-debugging-port=9223 \
+  --user-agent="$ua" \
+  --user-data-dir=/home/chrome/profile \
+  --no-first-run \
+  --no-default-browser-check \
+  --disable-gpu \
+  about:blank