Keep the admin surface local while serving tiles on the LAN

Binding to 0.0.0.0 used to demand credentials because the admin console and
the tile routes shared one listener. That forced a choice between keeping the
console off the network and letting other machines fetch tiles.

Admin routes are now loopback-only by default: the service can bind 0.0.0.0 so
/tiles, /vectors, the catalog and the probes reach the LAN, while /admin and
/api/v1/admin answer 403 to anything arriving from another host. Credentials
are only required when ADMIN_ALLOW_REMOTE=true actually opens the console up,
which is the case worth guarding.

Tests cover both sides: a remote admin request is refused, a remote tile
request still reaches the token check.

README.md

@@ -289,6 +289,10 @@ basemap, so they are guarded:
 - configure `ADMIN_TOKEN` for API clients (`Authorization: Bearer <token>`)
 - with neither set, the service **refuses to start** unless `API_HOST` is a
   loopback address (`127.0.0.1`, `::1`, `localhost`)
+- the admin surface is **loopback-only by default**, so the service can bind
+  `0.0.0.0` to serve tiles on the LAN while the console stays reachable only
+  from this machine; `ADMIN_ALLOW_REMOTE=true` opens it up and then requires
+  credentials
 
 Cross-origin requests are denied by default; add the exact origins you trust to
 `CORS_ALLOWED_ORIGINS`. Client tokens never appear in redirect URLs, and tokens
@@ -370,4 +374,4 @@ not supervised and does not survive a reboot.
 - no result artifact management
 - no raster processing jobs
 
-GIS software still produces the tiles and vector files. This project only scans, catalogs, authorizes, downloads, and pushes descriptors.
+GIS software still produces the tiles and vector files. This project only scans, catalogs, authorizes, downloads, and pushes descriptors.