New app route verified in a harness that bypasses the reverse proxy

A new unauthenticated route was added to an API and verified end to end — but the test harness talks to the API container directly, while the shipped stack puts a reverse proxy in front with an explicit path allow-list (e.g. Caddy '@api path /v1/* /install.sh'). The new path was not in that list, so in production it fell through to the catch-all and hit the frontend, returning an HTML 404 instead of the file. When adding a route, grep the proxy config for the path allow-list and the compose file for whatever mounts the asset the route serves — a passing harness test proves the handler, not the delivery path. Compounding it: the client script's error branch blamed a local permissions problem for what was actually a 404 from the server, so the failure sent users down the wrong debugging path.