🐛 Derive the URL scheme from APP_URL, not APP_ENV

[badmike]

A default self-hosted Docker install serves plain HTTP on localhost:8000 but generates every URL as https://, so the admin UI loads its HTML and then fails to fetch a single script or stylesheet. The browser reports that as a CORS error. Reported in #26.

The cause is using APP_ENV as a stand-in for "is this served over TLS". It isn't one: docker-compose.yml pins APP_ENV=production while scripts/install.sh writes APP_URL=http://localhost:8000, and AppServiceProvider forced https on any production environment.

APP_URL already states how the instance is reached, so the scheme comes from there now. Behind a TLS terminating proxy the operator sets an https APP_URL and the forcing still applies — including when TRUSTED_PROXIES is unset and X-Forwarded-Proto is therefore not believed.

EnsureRevision had the same defect. It passed the environment as redirect()'s $secure argument, which is an absolute override rather than a hint, so the delivery API's rv redirect went to https on a plain HTTP self-host and to plain http under TLS whenever APP_ENV was not production. It now leaves the argument out and inherits the same decision.

Verified

Built the image from this branch and ran the repo's own compose stack on OrbStack, APP_ENV=production and APP_URL=http://localhost:8123 like the installer writes:

image	asset origins in the served page
before	52 × https://localhost:8123
after	52 × http://localhost:8123

Before the fix, curl on one of those asset URLs fails the TLS handshake with no HTTP status. After it, the same asset serves 200 text/javascript, 753 KB. Restarting the fixed image with APP_URL=https://cms.example.com over a plain HTTP hop still yields https for all 52.

Hosted production is unaffected: both ECS task definitions set APP_URL=https://app.b10cks.com.

Two unit tests cover both directions, and both fail against the old code.

Fixes #26